[packaging] Meeting next week to discuss trusted third-party repositories

Peter Dolding oiaohm at gmail.com
Wed Dec 24 15:16:31 PST 2008


On Thu, Dec 25, 2008 at 4:58 AM, Wichmann, Mats D <mats.d.wichmann at intel.com
> wrote:

>
> > Experiences from trying to build a LSB application to
> > spec then testing it on different distributions over
> > time with updates.    Simple fact they break.   So over
> > time you end up shipping with more and more of the
> > runtime until you wakeup bugger will end up at one
> > point shipping all the runtime just to prevent glitches.
>
> Unrelated to this thread otherwise, could you send us
> (me?) some details on what you found, if they're not
> Things you've passed on to LSB already?
>

They have all ended up fixed eventually.  Best one recently was fedora
breaking there user packaging interface.   When you have someone using a
testing/development distributions its basically a shooting gallery.
Something will be stuffed in that distribution the question is do you depend
on it.  At different times everything included in LSB has been broken in
Fedora.   Its happened once nothing much is put in place to stop it
happening again.   Maintainers in Fedora  have a very bad habit of
disregarding complier warning messages after applying patches.

Sidux is taken straight from debian's sid tree that has no promises that it
will be stable either.   Basically same issue as Fedora another shooting
gallery that at different times everything included in LSB standard has been
stuffed even zlib.   Common cause defective complier.

As anyone from wine can state particular Ubuntu maintainers back port
patches without need quality control and against recommendations of the
developers of applications.

Debian forced to rename firefox to iceweasel due to backports some the
backports done by debian in stable also broke libnspr.

Basically backporting of patches is a common distribution thing and using
non peer reviewed patches.   Everyone of the current supporting
distributions of LSB are gulity of it.   Non peer reviewed patches and
backporting are really a risk since they add a random factor to the
operation of a runtime you cannot be sure that if it works with the source
from the main project that it will work right after they have been added.

Basically the complete idea that distributions are trustable is not backed
up with real world data.   Real world data says you cannot trust them.

If you could have produced real world data proven past any question that
distributions ever don't break things in the LSB runtime you would have
grounds to say trust them.   Problem here I could just keep on listing
through out the history of the LSB distributions breaking the runtime.

Trust is gained and lost through actions.   Yes ISV's applications should
try to use Distribution provided parts but should not be forced to use them
if they are broken.   If you disgree prove you case with real world data why
we can trust Distributions.   ISV's will want that paperwork anyhow.   I
suspect you will find exactly the same as me.

Peter Dolding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/packaging/attachments/20081225/023ba1b1/attachment-0001.htm 


More information about the packaging mailing list