Auto Package

[Mike Hearn]

On Tue, 29 Mar 2005 15:02:27 -0800, Matt Zimmerman wrote:
> New code brings with it new bugs, and the only way to find bugs is through
> testing.  One can't assume that the latest snapshot from the development
> team is any better quality than the current release; it must be tested.
> This is why QA departments exist.

Sure, but it also brings bug fixes. I think if a project is releasing code
that introduces as many bugs as it fixes this is just a bad project and
should probably have better QA, as you say. But that's upstreams problem.

> I don't think anyone would argue against "it would be nice if everyone
> standardized", but in practice this is a very difficult problem, and there
> is a great deal of inertia behind the existing solutions, which have years
> of proven robustness and stability.

Sure, but I still think a freedesktop.org style effort for distributions
would help a lot. An awful lot of things are different simply through
being apart, they don't lend any particular competitive advantage.

> It certainly is hard, but this has very little to do with the packaging
> format, and more to do with different solutions to the same problem.  As
> such, I don't see how autopackage addresses that problem any more than
> existing package formats do.

That's talked about a bit in the FAQ, there's an article coming up on
OSNews that discusses this in depth as well.

> I have faith in the possibility of cooperation and division of labor within
> the open source community ....

The thing with translation is it's done upstream, by people contributing
directly to the project. The translations then benefit everybody. If
Ubuntu tried to translate every program itself and those translations
weren't usable by other distributions, I think we'd be seeing exactly the
same problem.

> How did you find out that your software was not packaged the way you would
> like?  

A constant stream of bug reports that when investigated turned out to be
caused by broken packaging. Debian was not alone in this, Gentoo was the
next worst offender. In both cases the packaging for these distributions
was redone by upstream developers, and in both cases the robustness of
this software improved massively. Since we pulled Debian packaging
upstream there have been far fewer complaints and bug reports.

Yes, in theory all these bugs should have been reported to Debian first
then sent upstream. In practice they were not.

> There are good relationships between upstreams and packagers, and there
> are dysfunctional ones.  In a good packaging relationship, both parties
> know what to expect from one another, and the process overall works very
> well. Part of our goal is to make good packaging relationships easy,
> such that they become the predominant variety.

That's a noble goal for sure, but when upstream can simply do the work
themselves the whole problem of dysfunctional relationship disappears
(unless upstream is dysfunctional itself, in which case we have bigger
problems ...)

> I cannot accept responsibility for any comments made on Planet Debian
> (not even my own, since I don't write there).  I hope that you aren't
> equating my critique in this thread with those blog entries (which,
> while they raise some valid points, could have been more tactfully put).

I am not, no. You have been very civilised and this thread is a useful
one. I was pointing out that I understand what having your work disparaged
is like and I don't want to do that for others.

> The only thing which is centralized about Ubuntu is the infrastructure
> for building and archiving the packages and other output from the
> project.  

By "centralised" I mean all the packaging and software distribution is
done under the umbrella of the Ubuntu/Debian projects, instead of being
done upstream to upstream schedules.
 
> Is anyone building a distribution using autopackage?

No, it says in the FAQ not to try that. It's intended to sit on top of an
existing distribution managed using tools like apt, not to replace it.
 
> I would like to see this as well, but the model used on the Windows
> platform isn't applicable to open source ...

Windows may be a bad example, look at how Apple manage this. Generally
they rely on weak linkage much more heavily and applications do not
overwrite system libraries. Autopackage allows for both approaches, we
have tools that make weak linkage very each but also support dependency
resolution.

> I'm not as familiar with MacOS X, but Apple, I believe, uses a packaging
> format not entirely unlike .deb for packaging third-party software, so
> if they're meeting your requirements, it's not because of the format
> that they use.

No, the Apple techniques are nothing like apt or .deb. The PKG files are
more similar to MSI files. They aren't managed or controlled by Apple. The
"appfolders" are directories with some magic metadata inside, which are
allowed to depend on themselves and the OS but nothing else. There is a
very clear separation between the system and the applications, which is
why that works. Weak linkage is used instead of having applications
upgrade core OS components. 

This means it's more expensive, as you have to keep upgrading the OS to
stay current with applications. On Windows upgrading is used, so Sid
Meiers Pirates! works fine on Windows 98, an OS that's 7 years old now. So
users get a lot of value out of their OS purchase as it stays useful for
longer, but the downside is that this process was never really thought out
or managed and the resulting mess became famous.

On Linux I don't see why we can't combine both approaches to manage the
separation of operating system and applications.

thanks -mike