Re: Version naming

[Stephen Leake <stephen_leake@stephe-leake.org>]

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

>> I agree it would be nice to be able to do that in a single root, but I
>> suspect it is not possible in general, because there could be
>> conflicting requirements; you'd end up with full copies of /* for each
>> version anyway.
>
> I can't see why.  I already have emacs19, emacs20, emacs21, emacs22,
> emacs23, and emacs24 installed at the same time, so I can't see what new
> problem would be introduced by refining this to the minor
> version number.

For specific packages with similar dependencies, that works.

But suppose emacs19 depended on gtk1, and emacs20 on gtk2, emacs21 on
gtk3, etc. And each gtkn had different, changing dependencies as well.

You'd end up with unique copies of the entire dependency tree for each
emacsn.

In practice, since the dependencies are more stable than that, the total
tree would be much smaller than the full copy for each that you get from
the chroot approach.

I suspect, as has been said here before, the main problem is the
maintainer effort required to make installing minor versions in parallel
possible; renaming files to include version numbers in every file
name/path for each release. dpkg doesn't do that for you.

If you tried to upgrade dpkg to do the file/path versioning automatically,
it would have to take a very conservative approach, leading the full
copy as above.

That might work, but I suspect there would be problems; for example, if
C headers have "#include foo<version>;"; dpkg could not possibly be
expected to handle that by editing the file. Any hardcoded version in a
build script or source file would fail.

-- 
-- Stephe