[packman] [opensuse-factory] make it just work

Brian K. White brian at aljex.com
Mon Apr 11 22:22:20 CEST 2011


On 4/11/2011 3:16 PM, Greg KH wrote:
> On Mon, Apr 11, 2011 at 03:09:20PM -0400, Brian K. White wrote:
>> On 4/11/2011 12:28 PM, Greg KH wrote:
>>> On Mon, Apr 11, 2011 at 05:40:24PM +0200, jdd wrote:
>>>> Le 11/04/2011 16:56, Greg KH a écrit :
>>>>
>>>>
>>>>> Not true at all, this is up to the Packman developers, nothing the
>>>>> openSUSE developers can do about this for lots of various legal reasons,
>>>>> as has been stated numerous times here.
>>>>
>>>> well, if the legal problem impacts not only the distribution but
>>>> also the bugreports, this is a bad news.
>>>
>>> No, the issue is that packman bugs belong to packman, not to the main
>>> openSUSE bugzilla, as the openSUSE developers can do nothing about
>>> packman packages.
>>>
>>> It's just that simple, sorry.
>>>
>>> greg k-h
>>
>> You can't say that.
>
> Yes I can, and I did :)
>
>> There are countless examples of software that has to operate with
>> other software, and the cause of a bug that the user sees may
>> completely be in the "supported" software even though it only
>> appears when used in concert with some "unsupported" software. At
>> the very least such things should at least be investigated to
>> determine where the bug really is.
>>
>> Supported app crashes on start when unsupported library is used.
>>
>> The easy answer is "Doesn't crash with the supported library,
>> therefor not our problem."
>
> Yup.
>
>> Wrong for at least two reasons:
>
> Nope, for the reason you forgot, "We limit our scope of testing and
> support to the supported repositories".  Just like any other distro
> does, you have to draw the line somewhere, and this is where it is
> drawn.
>
> Again, like all other distros.
>
> Note, we will of course do our best to try to resolve issues whenever
> possible, but please, understand the issues here and the fact that "we
> will support any library from any repo combined with any application" is
> something that NO ONE does.
>
> Or if they do, they are insane, or lying, or both.
>
> thanks,
>
> greg k-h


Every system needs to support basic interoperability with other 
software. It's part of the very definition of practically every piece of 
software anywhere. OpenSUSE is not an embedded system with every byte of 
code absolutely fixed. It is a general purpose unix-like operating 
system, and using external software on it is part of the definition of that.

If it turns out that an external replacement for some normally supplied 
part behaves incorrectly that's one thing. But you can't avoid the need 
to find out which part is misbehaving. It's not automatically always the 
external part just because it's external.

Or, put it this way, does suse add a suse tag to the name or version 
numbers of the supplied libraries and compile all the supplied binaries 
to require those suse-versioned libraries explicitly? No they do not.
If the supplied binaries really did require suse-supplied libraries and 
_only_ those, the makefiles could absolutely be made to enforce that.

If I purchase a replacement math library that runs 200% faster from a 
3rd party, it's entirely possible that this external thing is wrong in 
some way. It's just exactly as possible that the replacement library 
adheres to the specs of the original correctly, only the original has a 
bug that the replacement does not have. That is a difference in 
behaviour that might adversely affect some app.
So, suse app + suse lib = no problem
suse app + other lib = problem
Except that's dumb simplistic short sighted logic.
It's dumb for suse to blindly support the bug in the broken library 
rather than fix the app that expects a bug or the stock library that 
supplies it. True, stuff like that is generally for upstream to 
duke-out, not a distributor, but it's still true that the bug could just 
as easily be in the distribution as in the evil external file. The 
distributors role may be as little as just to report the discovery 
upstream and try to incorporate any fix as soon as one is delivered from 
upstream, but the distributors role is _at least _ that, not just to 
ignore the problem without looking.
Or else, it's just not a very useful distribution. It may be pretty, and 
it may all work perfectly as long as you are willing to restrict the 
definition of "works" so narrowly, but that's not generally useful.
Is the point of the distro to make the distributor feel good or is it to 
be useful to users?

-- 
bkw




More information about the Packman mailing list