Auto Package

[Spark*]

I don't get this discussion... IMO, you are both sitting far too much
away from your side of the fence. Maybe come a little closer...
I think we can all agree that a central repository - like the excellent
Ubuntu main and universe repositories - are the easiest (possibly best)
way to get stable and well integrated software comfortably. It is also
a good idea to separate development from packaging efforts. 

But, we can't or shouldn't close our eyes to some simple facts:
- People are complaining all over the place, that installing third
party applications is too hard on Linux. This is one of the most often
heard complaints from Windows "power users". You might think that you
can solve the problem by just trying harder, but all evidence suggests
that we will _never_ reach the point where not installing a build
system is feasable for every user. The important point however isn't
which is the _right_ approach, but that autopackage provides a
significant improvement _now_, at no additional cost. 
- There are developers out there who WANT to provide binary packages.
Right now, they can't, because there is no kind of binary package
format that even has a chance to run everywhere (also deb packages for
example aren't well suited for single-download distribution) and most
do neither have resources nor time to create packages for all possible
distributions. autopackage is a great option for those developers and
many already make use of it. Nobody is _forced_ to create autopackages,
but who are you to tell developers they are not supposed to distribute
their own software?
- Many proprietary software vendors (like game developers) already
provide their own binary packages, just in a much inferior way.
autopackage would again be a method to improve the situation, at _no
additional cost_.

It seems silly to me to not even consider how to integrate autopackage.
It does not need this kind of goodwill and developers (and users) will
happily use it anyway. But there is a chance for you to improve the
user experience and you are passing it up for... what reason again?
Maybe there are issues that will have to be sorted out, maybe
autopackage needs to prove itself first... But I don't think it can be
ruled out completely, when it exactly addresses the issues of so many
people out there.

I was amazed by Ubuntu initially mainly because it appeared to think
fresh and out of the box. I would be hugely disappointed if it would
now join the club of the traditionalists, like so many else. 

Finally, let me stress again that I really absolutely don't think that
autopackage makes any of the current Ubuntu packaging work obsolete,
that's a great service which can't be valued high enough. But
autopackage would compliment it perfectly and it would be a win-win
situation, not a tradeoff. What would be harmed by installing the
support code by default (or optionally at first) and making sure that
autopackages integrate as well as possible? Nothing. It would still be
the user's own choice, if they want to make use of this facility or
not. It certainly beats configure; make; make install.

Daniel (not affiliated with the autopackage project in any way)


-- 
Spark*