Auto Package

[Mike Hearn]

On Tue, 29 Mar 2005 23:31:35 +0200, Sebastien Bacher wrote:
> I'm just curious but what happen in these cases ?
> 
> * an user installs gaim 1.2.0 with autopackage which breaks the login on
> ICQ account in some cases .. where is he supposed to do then ? How does
> he knows what upstream to contact and how (sf bug tracker ?
> bugzilla.gnome ? mail ?) ? 

The Gaim SF bugtracker of course, if an upgrade causes regressions then
this must be a bug in the software.

> * what is the upstream supposed to do ? Package the CVS ? Start updating
> the package with CVS backports ? I'm not sure than all the upstream want
> to start beeing packagers.

No, they do what all software vendors do for bugfixes: make a judgement
call about when the fix should be released. If it's urgent, like a
regression in ICQ support, a new point release can be done. In fact Gaim
have done this in the past for things like AIM.

Many users install from source anyway, so this isn't a problem upstream
can just ignore. In this case Gaim already produce autopackages, so the
moment a new 1.2.1 emergency bugfix release is made, there would be a
binary package for end users.

> * what happen if the bug is distro specific ? Are the upstreams supposed
> to know what every distribution is doing ?

How would such a bug occur? Often a "distro-specific" bug is really a
bug caused by a very new or strangely configured version of stock
software, eg the kernel. So you would have to fix it upstream eventually
anyway.

> * how do you handle distro changes ? By example we use sudo on Ubuntu,
> the different desktop component are patched for that. The autopackage is
> supposed to have special case for distros ? You say than the upstream
> job is easy because he has to manage one package and not a deb/a rpm/...
> but he has to know about such changes.

No, you deal with what the community are doing. If a significant number of
users don't have a root account, figure out a way to detect that and adapt
to it. Special casing is a bad plan because other distros may start
copying such ideas, especially in the case of things like sudo which is a
pretty good idea.

Sudo is a bad example because in this particular instance, we already
looked for a way to detect this setup and it's not possible without
authenticating. Autopackage itself can ask for the root password, so this
is something we need to fix. The probable solution is to ask for the
"system access password" then try it with both su and sudo: any other way
means mentioning obscure UNIXy terms in the UI which has poor usability.

Distribution specific policies like this very rarely affect packaging,
especially for end user programs like Gaim, Inkscape, AbiWord etc. I am
pretty sure we don't have distribution specific code in autopackage at the
moment, rather we detect the various setups in use (eg, Red Hat style
vFolder menus, Debian menu system, XDG menus, old style KDE menus etc
etc) and integrate with each one.

> Maintaining a package is not only making a autopackage/deb/rpm/.. of the
> new version, that's also to be sure then it works fine on the
> distribution and you need to know the distribution for that.

Generally it will work fine, there is a lot of code there to deal with
various things distros have done such as the various ways the
GNOME/KDE menus have been mangled. At the end of the day it's 99.9% the
same software running the show.

I think you're overestimating how much distribution-specific integration
your average program requires. There are programs that require a lot but
they are the exception rather than the rule.

thanks -mike