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

[Peter Dolding]

On Wed, Dec 24, 2008 at 12:44 AM, Denis Washington <dwashington at gmx.net>wrote:

> Peter Dolding wrote:
>
>> So as a ISV I will choose .run or 0install or tgz or some other solution
>> that does not care about distributions so I can install on as many
>> distributions as able.   So effectively LSB dies in time if a perfectly
>> solution ever appears.  Reason why ISV will choose something like 0install
>> so they don't have users bugging they why they did not support a strange
>> distribution.
>>
>
> My feeling is that our view on the LSB is entirely different.
>
> For me, the LSB is a set of cross-distribution base system and interface
> guarantees, practically the equivalent of the base systems of
> single-distribution operating systems. An ISV that develops for Windows or
> Mac OS X trusts the base system and the runtime these systems provide. No
> third-party application on these platforms would come with copies of these
> systems' foundation libraries just because Apple or Microsoft could,
> somehow, somewhen, "stuff them up". Relying on the operating system vendor
> is a natural requirement for every software developer. For me, the LSB is
> the same in the context of the multi-distribution Linux landscape: a single
> base system *you, as ISV, can rely on*.
>
> You, on the other hand, see the LSB as a papercut that can *never* be
> relied on.


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.

>
> From these very different perceptions of the LSB, we naturally come to
> different conclusions. You, not believing in the LSB, like to have a
> completely distribution-independent parallel runtime, bottom to top, for
> third-party applications; a copy of essentially everything provided by the
> distribution because its runtime, in your opinion, cannot be relied on the
> least bit.


You have me party wrong here.   Prefered for me is that applications use
distribution runtime reduced uploads for ISV's cost saving.

But in case of issues there needs to be a clean and effective system to
override distribution runtime.   So lets say no distribution gets glibc
wrong there would be no need for a override to exist.  Problem is currently
LSB provides no system that ISV's can say if it don't work due to a
distribution glitch they can do anything about it other than ship the
runtime in all future versions of there application effectively expanding
size of application and secuirty risks.  Currently from a simple cost point
of view 0install is cheaper.

If valid system for overrides and shared runtimes if user finds they need a
lot of overrides to make LSB applications work in there distributions it a
clear sign that things the distribution they selected is either being poorly
maintained or running a lot of experminental stuff.

Blame goes where it belongs.   LSB model currently means defective runtime
in a distribution can end up blamed on the ISV not supporting that
distribution.   ISV is better not to support Linux at all than get in the
middle of distribution politics.

>
>
> But I believe in the LSB's merits. I believe that we *can* rely on the LSB
> base system and the runtime it provides, as every other operating system's
> runtime is relied on. Let's not daemonize the distributors as unreliable
> because they, in theory, *could* break their compliance promises, but just
> trust their ability to build a reliable, stable runtime platform for
> third-party software, as many have proven long enough. Of course this means
> that each application will have to ship a copy of their dependencies that
> are not covered by the LSB, and of course this will mean duplication to a
> certain degree, but this is, in every case, preferable to a system that
> encourages a culture of distrust between third-party software providers on
> the one and distributions on the other side; with such a culture, such a
> source of hatred between core system developers and independent software
> providers, the rise of Linux will fail miserably.
>
> For this reason, please, reconsider the LSB as a reliable building block
> for the future of Linux software deployment. Otherwise, I see no further
> ground for our discussions.
>

Problem you are not getting here.  Current design LSB design is unreliable.
  Not all distributions have good maintainers this is a simple fact.
People running like fedora a testing ground for experimental code of course
will never be reliable platform for a LSB runtime.   Even Ubuntu will use
experimental patches.

This is the brick wall.   ISV's don't want bad press like application does
not work on Ubuntu so users go to competitor.   Distributions even do manage
to break compatibility with there own packages let alone LSB ones.  Like
installing applications that need mpeg processing and will crash with out it
Ubuntu does this.   Reson they altered a lib applications have all there
dependances meet only one problem 1 of the dependances don't work.

Ok if Distributions never ever broke compadiblity with there own packages
leading to applications failure you might have a leg to stand on that LSB
can work.

I see LSB as something just by adding support for runtimes number 1 becomes
a truly reliable system.   Number 2 promtes runtime sharing between
distributions.

Linux Standard Base is about bring distributions to a common core.    Key
objective of Linux Standard Base is to allow ISV's applications to operate
on other distributions.   Remember distributions themselfs are ISV's.

You line is exactly the same as saying I should trust that my harddrive does
not fail so should not make backups of my data when you are saying I should
trust distributions to get it right.   I want a plan B.   If plan A
distributions providing runtime fails.  I want a dependable fall back
location in plan B.   You cannot promise me plan A will not fail from time
to time it has failed in the past and will fail in the future this is just
the way it is.

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