Auto Package

[Matt Zimmerman]

On Tue, Mar 29, 2005 at 09:02:36PM +0100, Mike Hearn wrote:

> On Tue, 29 Mar 2005 11:33:16 -0800, Matt Zimmerman wrote:
> > I entirely disagree; the reason we provide stable releases is because users
> > want them.  Distribution developers generally follow the leading edge.
> 
> I'd say users actually want the ability to install up to date software,
> without hitting the "E: Broken packages" error (and without having it mess
> up menus etc). Package/repository freezes are one way to accomplish that,
> but they're a means to an end from Joe Users perspective. There are other
> means to that same end.

Users want a system which, as a whole, is well-tested and in good working
order.  This is in direct conflict with continously pushing new code.

If you know of a way to provide stability without testing, or testing
without time, then the open source community would like to hear from you.
:-)  What means do you have in mind?

> I think this is the main philosophical difference. You see the "system" as
> being everything that Ubuntu ships in main, whereas I see the system as
> more the core of the OS plus a few must-have utility apps. Pretty vague I
> know, what Windows/MacOSX ship is a fairly good template. So GNOME would
> be in the core, whereas Inkscape wouldn't be. And Gaim is an edge case.
> 
> So I'd say the things that make Ubuntu attractive are features of a good
> operating system. That means slick desktop, good installer, UTF-8 by
> default, good tech support and so on. The type of things that make MacOS X
> good despite not having apt, in other words.

One of the ways in which open source platforms are superior to these
commercial offerings is that they provide a rich set of software, not just a
base to which the user must add things that almost everyone needs.  Building
and testing them as an integrated whole means better QA and a better user
experience with these programs.

What it sounds like you're saying is that packaging is only useful for
infrastructure components; if so, I could scarcely disagree more.

> > The issues you raise are:
> > 
> > - .deb packaging is too complicated.  The solution to this is to make
> >   .deb packaging easier, not to replace a mature and robust packaging
> >   system with something more like autopackage.
> 
> I don't think this is really true and it's certainly not an issue I
> raised.

I work on .deb packages for a living, and I think it's overcomplicated.
You said that one of the obstacles was finding someone with the
skills/knowledge to create packages; there would surely be more such people
if the barrier to entry were lower.

> > - There is sometimes a shortage of motivation to create packages.  This
> >   is not a technical problem, and is shared equally by any packaging
> >   solution.
> 
> I disagree. If a developer of a cool new widget could make one package,
> that works for all Linux users (that's a huge portion of their userbase,
> most likely) that does increase the incentive to produce a package over a
> kind that only works for maybe 5% of their userbase.

Packaging formats are essentially a non-problem.  We already have a tool
(alien) which can convert (NxN) between rpm, lsb, deb, tgz and Solaris pkg
formats.

The issue is that different platforms have differing requirements for tight
integration with the rest of the system.  Things like conffiles,
alternatives, diversions, packaging policy, dependencies, etc.  These are
the things which represent the value in a distribution.  They are also
precisely the things which fall out when aiming for the least common
denominator.  This level of integration is only possible when all packages
involved are speaking the same "language", targeting the same platform.

Thus, "Everyone could just use autopackage" isn't a significantly stronger
argument than "Everyone could just use (deb|rpm|...)".

The solution proposed by autopackage is to push the packaging burden
upstream, by having the developer also act as the integrator.  The primary
advantage of this would seem to be that (if somehow successfully
implemented) a larger number of people would be working on the problem.
In all other respects, though (functionality, coordination between
developers, robustness, QA) it's a step backwards.  This is how people
managed software before we had packaging systems, and its problems are the
reasons why packaging systems and distributions evolved.  It was a mess!

> > It doesn't provide any packaging metadata, either.  No debian/, no
> > .spec, no .package.
> 
> No, but Murray Cumming has said before that he was going to stop
> development on Glom for a while until it was packaged, because otherwise
> it was too hard to get lots of testing (I paraphrase, but that was the
> gist of it). Maybe if he only had to do it once, he would have produced a
> package. Yes, it's speculation ...

It sounds like his problem is packaging-system-independent.

> Well, I believe this is optimising the wrong design. Unless Debian or
> Ubuntu become the de-facto standard Linux distro I don't think it would
> ever be guaranteed that a user always has an up to date package available.

You'll find that when it comes to open source development, "Your design is
wrong, put your efforts into writing it my way instead of yours, you're
doomed to fail anyway" is not a successful motivational approach.  This kind
of discussion happens all the time, and is, as a rule, a waste of time.

Indeed, many open source developers find it somewhat offensive when their
work is disparaged in this way.  I'm doing my best to respond to your ideas
rather than your tone, but bear in mind that this will hamper your progress
if you hope to sell your idea.

The strongest sales pitch in the open source world is "Here's the code, I've
shown how this idea can work, you can see for yourself that it's better."

> This is the guarantee that MacOS X and Windows provide, so to be
> competitive with them we must also provide it.

In what way do they provide such a guarantee?

> But how can we, when even with over 1000 volunteers Debian has not managed
> to do this?

By finding more effective ways to work together, both within Ubuntu and in
cooperation with other parts of the open source community.

-- 
 - mdz