Re: address@hidden: Re: Possible help with stable Emacs releases.]

[Rob Browning]

Stefan Monnier <address@hidden> writes:

> Just as it is possible if you don't use packages, it should be
> possible for the end user to decide that she wants to install Emacs
> versions 20.3, 20.4, 21.1, 21.2, and 21.3.

We probably could do that for many packages.  Often it comes down to a
decision based on the available manpower as compared to the value of
providing additional revisions, though if all packages were to do it,
it might also come down a decision based on the load on the
infrastructure.  It looks like we already provide over 15000 source
packages just in testing and unstable, and the number of actual
packages will be much more than that, related to the number of
architectures we support.

> Using package systems like `depot' or `stow', I haven't had any trouble
> with any existing package.  No need for special support from the
> upstream developer.

OK, well for now, I'm not familiar enough with them to meaningfully
debate their merit as compared to apt, dpkg, and Debian's current
policies.

> You don't need to change the name, just the directory in which to
> search for the lib.

The problem is that then -L linking will fail unless ld.so has also
been augmented with these paths, or unless the user has added that
directory to their LD_LIBRARY_PATH.  I'd still like to see dlpen
support for the algorithm that the normal linker uses, so you can tell
dlopen to open libbar version 4, and let it find the latest suitable
revision (i.e. the same one -L linking would find at runtime).

In any case, I suppose this is all somewhat off-topic.  The only plea
I'd like to make is that if possible, Emacs use some versioning
strategy where there's at least one number or numbers that changes iff
substantial backward compatibility is introduced.

-- 
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