Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning <rlb@defaultvalue.org>]

Stefan <monnier@iro.umontreal.ca> writes:

> While I mostly agree that we should change emacs-major-version for
> non-bug-fix releases, I think that limitations of specific packaging
> systems are not a motivating factor.

Perhaps not for you, though upstream can be a *great* help when their
versioning behaves sanely.

> I actually think that your problems should cause you to reconsider
> the design of the packaging system since such problems surely happen
> with other packages as well.

I'm not sure what kind of improvements you're suggesting, and for
which kinds of problems, but I don't recall a situation where we
*can't* accomodate multiple installs of something in Debian.  It's
just a matter of how much hassle it is and how far we have to diverge
from the upstream code, and that's usually determined by how much
attention the upstream developers have paid to the issue.  (It's also,
depending on the package, a question of manpower.)

For example, if emacs started making releases with major breakage that
only bumped the third version number, i.e. 21.4.1, then (as Jerome
suggests) we'd just have to start releasing emacs packages which
include all three versions: emacs21.4.1.

All that said, by all means, if you can suggest improvements, please
do.

>         Stefan "who's generally disappointed by the poor support for
>                 multiple concurrently installed versions of a single package
>                 in most package systems"

This blame (though not generally in the case of emacs) may lay as much
at the feet of the upstream developers as the downstream packagers
(speaking as one who works on both sides).  If the upstream hasn't
ever considered the problem, then it can be very difficult, and
require substantial hacking, to alter the upstream to handle multiple
installed versions.  This can be further hindered by the available OS
and tools.  For example, the fact that dlopen doesn't support
versioning the way that ld.so does can make it difficult to allow
multiply installed versions of software that relies on dlopened
libraries, unless the upstream has considered that problem and chosen
suitably unique library *names* for those libraries.

The more classic example is an upstream that doesn't bump its library
soname versions when making backward incompatible changes to the
code.  This can be a big problem.

All of these examples assume that the distribution is going to try to
conform to the FHS.  If you're willing to ignore that, then you may
have other options.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4