Re: AutoPortage

I didn't really see this entry in the FAQ as applying, at first, since you
were talking about a centralized package repository and I was talking about
a ports/portage system for version tracking, compilation, and package
production.

> The system of attempting to package everything the user of the distro
might ever want is not scalable. By not scalable, we mean the way in
> which packages are created and stored in a central location, usually by
separate people to those who made the software in the first place. There >
are several problems with this approach:

I agree and, moreover, for a distribution to package and support all the
software that runs on it diverts attention away from maintaining a quality
platform and quality applications.  A distribution will be better if it just
focused on being a platform on which software installs and runs well.  And
the applications would be better for people if each package were maintained
by those who specialize in the specific application.

   - Centralisation introduces lag between upstream releases and actually
   being able to install them, sometimes measured in months or years.

Indeed.  It does create lag and that effects me, personally.  I am running
Kubuntu with separately downloaded OpenOffice 3 and VirtualBox because the
maintained packages are too out of date for my needs.  Before downloading
them, I first checked the autopackage repository and did not see them
listed.  So, we've got lag with autopackages, too.. Even worse.. Far fewer
packages with even more lag.  Clearly, this is because the software
maintainers don't supply their software using autopackage... But that's a
reality.  An AutoPortage system would make this far easier for a maintainer
to do or someone else, if the maintainer is unwilling.  New versions, in
most cases, should be little more or no more than just pointing to the
latest version of the source..

   - Packaging as separate from development tends to introduce obscure bugs
   caused by packagers not always fully understanding what it is they're
   packaging. It makes no more sense than UI design or artwork being done by
   the distribution.

This is true.  But it beats not having the package at all.  If the
maintainer won't do it then that doesn't mean nobody should.

   - Distro developers end up duplicating effort on a massive scale. 20
   distros == the same software packaged 20 times == 20 times the chance a user
   will receive a buggy package. Broken packages are not rare: see Wine, which
   has a huge number of incorrect packages in circulation, Mono which suffers
   from undesired distro packaging, etc

Exactly..  That's why we love autopackage.

   - apt et al require extremely well controlled repos, otherwise they can
   get confused and ask users to provide solutions manually : this requires an
   understanding of the technology we can't expect users to have.

Right.  Each distro has a package hierarchy for each release that is only
maybe somewhat compatible with each other.  And then the documentation hell
makes this even worse--Google searches yield mostly out of date help and
often packages installed, leave the user wondering even how to start the
application.

   - Very hard to avoid the "shopping mall" type user interface, at which
   point choice becomes unmanagably large: see Synaptic for a pathological
   example of this. Better UIs are possible but people fundamentally don't
   expect a big central list of programs, when they are used to a search based
   interface like Google. Imagine if the same UI were used for locating
   websites!

Unfortunatley, I don't see autopackage solving this problem.  There is just
a big list of autopackages on the autopackage web site.  Directories could
be easily built that resolve this problem, such as that tag application with
their capabilities, provide ranked user reviews, and both official and wiki
documentation.  Perhaps you've all been thinking user's should just google
to find individual project sites, download and use..  There's nothing wrong
with that, but a central search, review and at least user generating
documentation would make it much easier on users.

   - Pushes the "appliance" line of thinking, where a distro is not a
   platform on which third parties can build with a strong commitment to
   stability but merely an appliance: a collection of bits that happen to work
   together today but may not tomorrow: you can use what's on the CDs but
   extend or modify it and you void the warranty. Appliance distros have their
   place: live demo CDs, router distros, maybe even server distros, but not
   desktops. To compete with Windows for mindshare and acceptance we must be a
   platform.


Yes.. Well, I think it's tragic that the generally notion of a distribution
is that of a OS + software instead of an OS that runs software.  Once people
conceptualize in such a way, it's not easy to change them.  People defend
what they are used to regardless of how much sense it makes.  They'll always
have their reasons.  It's psycological thing.  They'll invent every reason
they can.

I think the only way to combat this is to show them something better.
Autopackage is technical capable of being that something better but I am
getting the sense you all might be similarly unwilling to accept change
where it is needed.  It would great if every software developer produced and
supported autopackages but the fact is, they don't.  Theory is not meeting
reality and another measure is needed, if at least a temporary measure.
Only when autopackages are available to the point of a certain critical mass
will developers, generally, begin to accept and adopt it.

Therefore--I am thinking of an AutoPortage facility for maintaining
autopackages.  That is, something that'll enable mass production of them,
with and/or without the direct involvement of software developers.  That is,
with the ultimate goal of getting developers to maintain them, themselves,
or at least to "sponsor" and work with maintainers of their work.

Matthew


On Thu, Dec 25, 2008 at 7:57 AM, Mike Hearn <[email protected]> wrote:

> It is definately there, see the question about centralized repositories.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
> For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]
>
>