Steve Langasek writes ("Re: Please test gzip -9n - related to dpkg with
multiarch support"):
> And what about adding 700 packages vs. adding no packages at all, in the
> case of systems which aren't going to have multiarch enabled?
One thing that seems to have been overlooked in this discussion of
splitting is that splitting packages is not a completely neutral
operation, semantically.
The package is the unit of installation and upgrade; dependencies do
not prevent a package from being on the system for a considerable time
with its dependencies violated.
Or to put it another way: if currently
libfoo1 (1.1) contains and needs /usr/share/libfoo1/foo-data-1.1
libfoo1 (1.2) contains and needs /usr/share/libfoo2/foo-data-1.2
then splitting the foo-data out into
libfoo1-data (1.1) <-depends- libfoo1 (1.1)
libfoo1-data (1.2) <-depends- libfoo1 (1.2)
means that when the libfoo packages are upgraded, there will be a
substantial period when we have /usr/lib/libfoo1.so.1.2 installed and
the symlink libfoo1.so.1 points to it, but
/usr/share/libfoo2/foo-data-1.2 is missing.
If the packages are not split, dpkg will unpack
/usr/share/libfoo2/foo-data-1.2 before overwriting the old
libfoo1.so.1 symlink. So normally, our current arrangements mean that
shared libraries continue to work throughout an upgrade. Splitting
shared data out like this may make this no longer true (for some
unknown set of packages).
This issue is very important for essential packages, but in general
it's not a good idea to introduce additional sources of skew. For an
essential package the problem can be solved with a Pre-Depends but the
result has to look like this:
libfoo1-data1.1 (1.1) <-depends- libfoo1 (1.1)
libfoo1-data1.2 (1.2) <-depends- libfoo1 (1.2)
So I think the refcounting in dpkg is the best option for these files.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20280.65534.54525.328...@chiark.greenend.org.uk
