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

Peter Dolding oiaohm at gmail.com
Wed Dec 10 05:14:07 PST 2008


On Wed, Dec 10, 2008 at 11:03 AM, Yfrwlf <swiftpaw22 at gmail.com> wrote:
> Tortanick wrote:
>> On Monday 08 December 2008 07:53:59 Peter Dolding wrote:
>>
>>> Linux Distributions have always been fighting over there own package
>>> formats.  Models the Distributions are putting forward are all
>>> designed to leave them 100 percent control of providing the runtime.
>>>
>>
>> Good, the distributions are better at it than me. I'm happy to let them do the
>> work and just leave a few hooks for me to insert a customisation or two.
>>
>>
> You want to rely on distro companies to repackage your software for you
> instead of getting it directly from the programmers?  Did a distro
> company pay you to say that?  I don't know why any sane Linux user would
> ever say they'd want something like that, to be essentially locked into
> a certain repository and company.  Distros have become middle-men, and
> they need to be cut from the picture as far as locking users into their
> repos.  If Red Hat, Novell, or Canonical want to stay in the business of
> sponsoring Linux software projects, by all means I hope they keep doing
> so.  If they want to offer paid development support for a certain range
> of programs, by all means keep doing so.  However, this model of locking
> users into the old, annoying Linux model of keeping users dependent on
> distro companies needs to die.  Linux users deserve more freedom than that.
>
> Providing Gnu/Linux software bundles or mirrors/repositories of programs
> which you can also get directly from the dev's website = OK.  Locking
> users into those same repositories and not allowing them to "roam free"
> = bad.
>>> This effective means we stay with the same crap system we have now.
>>> Where each distribution customizes there own packages independent to
>>> each other and millions of build hours are year are wasted building
>>> the same application for multi-able distributions.
>>>
>>
>> Machine time is cheep, what would you have those servers do instead?
>> SETI at home?
>>
>>
> If a company CEO heard you, you'd be fired, and I have to say that
> response to Peter's comment was in very poor taste.  Do you know why
> virtualization is popular?  That's because it means you can condense
> down your physical servers by throwing multiple OSes into VMs if you
> need that separation there between OSes as certain businesses do
> (hosting providers for example, as well as for other reasons).  Having
> less wasted CPU time is what companies want.  Linux has wasted who knows
> how much energy by recompiling everything a million times redundantly
> when it only needs to be done once by the original developers, and then
> additional times by anyone who wants to look at the code and compile it
> for whatever reason, or contribute code to the program themselves.  We
> want freedom *and* ease of installation and it's very possible to have both.
>>> To reform Linux in to something majority useful to ISV's.
>>>
>>
>> Linux is already "majority useful" to me, and I think most Linux users will
>> say the same thing, I would not reform something that is very useful and risk
>> loseing the current user base to try and attract ISVs.
>>
>>
> It'd be a lot more useful to normal computer users if they could easily
> install whatever software they wanted to without being trapped in a
> specific company's walled garden.  More developers could target Linux.
> Not just companies (ISVs), but both open and closed source developers,
> working within companies or on their own, i.e. *everyone*, could simply
> release one pacakge and be done with it.  Supporting and developing
> Linux programs would be easier all around, and when there is money
> involved, it'd also be cheaper.  This means more programs for Linux.
> More programs for Linux means even more programs for Linux, and the
> snowball effect ensues.  All this ends up meaning *you* have more
> programs to use, if you use Linux.  It benefits everyone in every way.
> Except Microsoft and Apple.
>>> LSB basically has to break the distribution model completely.   Repo idea
>>> is all about central source providing of applications.
>>>
>>
>> Were trying to make it easy for ISVs to package software, oppsing
>> distributions is not going to work because:
>> a) Nearly all Linux users like distributions
>> b) If the distributions don't support the LSB, the LSB will have no users. No
>> ISV will package for something that has no users.
>>
>>
> They like it?  How about that's the *only* way they can get it easily is
> in software bundles, which there is nothing wrong with, it's being
> locked into repos that's the problem.  Users don't "like" it anymore
> than they "like" Windows in the past just because Windows provided them
> with a semi-functional computer.  In other words, no, Linux users like
> freedom, and a feature that gives them more freedom is exactly what they
> want.
>>> ISV's and
>>> Distrobutions really need a Distributed package providing system.
>>> Think about a Direct X game they ship with a Direct X runtime provided
>>> by Microsoft that updates by Microsoft.  Advantage of this ISV does
>>> not have to take on the maintain cost of Direct X.
>>>
>>
>> The problem is that your not just asking Microsoft to maintain DirectX, your
>> asking Microsoft and the user to co-maintain it. DirectX is a bad example
>> because its an extreemly popular libary with a major ISV behind it. But if
>> you allow distriubted dependencies and a small ISV vanishes taking its
>> libaries with it, or they break backwards compatability, then you've created
>> dependency hell. Its just not worth the risk.
>>
>>
> Linux already has dependency hell.  A better package management system
> will thwart it.  Direct X came with all the libraries needed for it
> other than Windows itself.  Here's my idea:
>
> User is on a website.  They click a link to download a file, click OK or
> whatnot, and download and open it with their package manager.  In the
> package are the needed GPG keys or whatnot along with URLs pointing to
> the actual files.  You could contain everything that is needed in the
> package itself, or you could have the package be basically a downloader
> via the package manager.  In either case, you could have URLs that point
> to a location for program updates.  Now, if the file was small and
> simply some URLs and keys or whatnot, the package manager could
> intelligently download only those dependencies that it sees it needs.
> The packages contain all the information for the manager to successfully
> install the software.  As long as you have a method to work out name
> conflicts, even have a name register or whatnot like for domain names or
> just use a simple renaming scheme with a dynamic system that allows
> software to know where everything is located, then the package manager
> can put files where ever the hell it wants to, where ever it's
> configured to.  Such a system may require that programs are made to use
> the system, but I don't think it'd be too hard, perhaps just make some
> special characters or something to represent dynamic locations.
> Whatever.  It's all doable though, that's all I know, it's just
> software, it doesn't control you, you control it. :)
>>> Then there are
>>> closed source audio frameworks applications could be using and so on.
>>>  KDE and Gnome have there run-times.  There is no reason why KDE and
>>> Gnome with means to release direct could not complete directly with
>>> Distributions on features and style yet still remain 100 percent
>>> distribution neutral.
>>>
>>
>> Go ask KDE and Gnome weather they want to do all that extra work then post
>> back their awnsers.
>>
>>
> The KDE and Gnome developers would love being able to compile their
> stuff once, and be done with it.  Their sites would get a lot more hits
> and the Gnome and KDE projects would thus get more exposure than they
> are now.  When an update came out, especially, users would be flocking
> to download or update their software directly from them instead of just
> primarily some middle-men companies.  Linux users would be finally very
> free to easily get their software directly from the sources.
>>> Simple fact if other parties get into the configuration game and do it
>>> better than Distributions in a cross Distribution way distribution
>>> importance could disappear.
>>>
>>
>> Ok then, go out there and create a better system than the distributions, in
>> the mean while the easiest way to support ISVs on Linux is to make it easy
>> for them to create cross distro packages so I guess that's what the LSB will
>> be doing.
>>
>>
> I'm pretty sure that's one reason why he's here, is to see a better
> system be created, and one which doesn't require some company's software
> repository is best.  He was saying that anyone could then provide
> software mirrors/repositories that are actually usable by all Linux
> users, which would mean distro repos wouldn't have to be depended upon.
> More freedom.
>>> This also forces Distributions to
>>> provide better quality applications since if they hand up poor quality
>>> users will be able to avoid the distribution repos.
>>>
>>
>> Nope, distributions have to provide high quality because if they don't people
>> will move to the other distributions. That's the beauty of the "infighting"
>>
>>
> And if that infighting happened directly between software like it
> should, instead of effort being wasted on recompiling and providing 50
> different software packages because there isn't at least one open
> standard which has been adopted into the major package managers like
> there should be, we'd have better software.  If users were free to
> install any of the new or "niche" software or whatever versions of that
> software they wanted to, regardless of their Gnu/Linux version they were
> running, they'd have much more freedom.  That's a lot more beautiful
> than the current situation.
>
>
> We (Linux users) want change.  I speak for myself and everyone else who
> has been subjected to the lovely (sarcasm) software garden wall which
> Linux has created because of the distro ecosystem which has arisen,
> profiting off their users being dependent on them.  That needs to end,
> for a plethora of reasons ultimately because *we want it to end*.
> You're right that no one needs to ask for permission to fix this mess,
> but it does need to be spoken about more.  The standards groups like the
> ISO, LSB, LF, Freedesktop, etc, need to push for a good, open Linux
> packaging standard which the major package management software can
> easily adopt (most likely while still keeping their own format
> compatibility, at least for a while).  If these standards groups don't
> want to help in doing that like because they are bought out by distro
> company interests or whatnot, we'll go elsewhere.  Like to Zero Install,
> Klik, or other systems which allow us to have access to the software we
> want without having to beg a distro company or try to get it packaged
> for their proprietary system.
>
>
> -Yfrwlf

One thing Yfrwlf did not say is that Zero install and Klik were put
forward as possible packaging models for the LSB.   Major reason why
they are not yet is lack of formal way to register there files in the
packaging system.  Yes either one could be the formal package format
of LSB in time.

If you please read the
http://www.linuxfoundation.org/en/Berlin_Packaging_API  You will
notice its format less.  Once LSB has that it can start experimenting
with all kinds of distribution disregarding frameworks.

Deb and rpm are not planned to be included at all in future LSB.
Instead we return to the world of executable installers.

Basically LSB is out of tolerance for all this Distribution stuffing
around and not taking on the problem.   If we have to make it worse so
Distributions get off there back sides so be it.  Lack of
Distributions sorting it out is bring this.  Only way LSB will stop
from it's current path now is a suitable solution.

Come back with a solution that works for everyone ie Users ISV's and
Distributions and we might be getting somewhere.

Peter Dolding


More information about the packaging mailing list