[Gllug] Debian 32/64 bitness

[Peter Grandi]

>>> On Sat, 15 Oct 2005 18:48:19 +0100, Nix <nix at esperi.org.uk>
>>> said:

[ ... ]

nix> Your proposed solution brings *nothing* and actually adds
nix> complexity and reduces transparency.

It is not my «proposed solution», I was trying to describe what
is done by those distribution that do not require the 'chroot' or
''wrapper/launcher'' workarounds, because they use package
managers that already support ''multiarch''.

[ ... ]

nix> And if you can't answer the question of whether two
nix> versions of a package can coexist or not, the entire
nix> packaging system falls apart.

Under Debian (and most other distributions) this can be easily
handled with existing directives:

  http://WWW.Debian.org/doc/debian-policy/ch-relationships.html

   «Conflicting binary packages - 'Conflicts'

    When one binary package declares a conflict with another
    using a Conflicts field, dpkg will refuse to allow them to
    be installed on the system at the same time.»

Besides the core issue here is whether two different _arch's_ of
the same same souce package can coexist, and the version issue
was just an illustration of a similar limitation with a slightly
different flavour.

[ ... ]

nix> Well, actually, no, you'd need a special version of the
nix> amd64 package anyway. Both these package contain files with
nix> the same names (in /usr/share/doc if nowhere else).

Under Debian (and most other distributions) this can be easily
avoided by using '-doc' or '-common' packages:

  http://WWW.Debian.org/doc/debian-policy/ch-docs.html

   «If a package comes with large amounts of documentation which
    many users of the package will not require you should create
    a separate binary package to contain it, so that it does not
    take up disk space on the machines of users who do not need
    or want it installed.»

which are already often used (not often enough I reckon), for
example these are the '.deb's for DPKG (note how small the '-doc'
is, BTW):

----------------------------------------------------------------
lftp> dir dpkg*1.10.28*.deb
-rw-rw-r--    1 1176     1176       166246 May 26 18:02 dpkg-dev_1.10.28_all.deb
-rw-rw-r--    1 1176     1176        10620 May 26 18:02 dpkg-doc_1.10.28_all.deb
-rw-rw-r--    1 1176     1176      1970740 May 26 19:47 dpkg_1.10.28_alpha.deb
-rw-rw-r--    1 1176     1176      1895740 May 27 10:03 dpkg_1.10.28_arm.deb
-rw-rw-r--    1 1176     1176      1934920 May 27 04:32 dpkg_1.10.28_hppa.deb
-rw-rw-r--    1 1176     1176      1892234 May 26 18:02 dpkg_1.10.28_i386.deb
-rw-rw-r--    1 1176     1176      2040196 May 27 04:17 dpkg_1.10.28_ia64.deb
-rw-rw-r--    1 1176     1176      1869852 May 27 08:47 dpkg_1.10.28_m68k.deb
-rw-rw-r--    1 1176     1176      1936358 May 27 16:02 dpkg_1.10.28_mips.deb
-rw-rw-r--    1 1176     1176      1931170 May 26 19:47 dpkg_1.10.28_mipsel.deb
-rw-rw-r--    1 1176     1176      1919034 May 26 19:47 dpkg_1.10.28_powerpc.deb
-rw-rw-r--    1 1176     1176      1918022 May 29 17:32 dpkg_1.10.28_s390.deb
-rw-rw-r--    1 1176     1176      1897292 May 27 10:03 dpkg_1.10.28_sparc.deb
----------------------------------------------------------------

  Note: unfortunately there are quite a few things in the 'dpkg'
  packages above that should be indeed in 'dpkg-doc', but that is
  just objectionable packaging practices, nothing new here :-(.

The '-doc' package has architecture 'all', as it happens that
Debian policy also recognizes the existence of stuff that is not
architecture dependent, like most documentation:

  http://WWW.Debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture

   «* 'all', which indicates an architecture-independent package.»

This to me seems all easy and proper, if not practiced as often
and wisely as it should.

>> The basic problem is that the DPKG/APT combination only looks
>> at the package base name, not at all three/four parts of the
>> full name, so if you have 'libdb-4.3.28-3_i386.deb' and try to
>> install 'libdb-4.3.28-3_amd64.deb' that is a replacement /
>> upgrade (same base name), not a separate/parallel install.

nix> Utter nonsense. It looks at all parts of the name *and this is
nix> documented in Debian Policy*.

Amazingly, a few lines earlier I can read:

  nix> With the current rule (only one version of a given package
  nix> installed at once), it is trivial for both humans and the
  nix> package manager to tell whether two packages can coexist:
  nix> if they have different names and do not conflict, they can
  nix> coexist: if not, they cannot. The rule is absolute and
  nix> very simple.

where it seems to me that by «package name» you mean here the
base name, as you write «only one version of a given package».

>> For this reason Debian package names have the major version
>> appended as a suffix [ ... ] the ABI version of the C++
>> library they depend upon appended to the base name; sooner or
>> later we shall see the architecture type appended too, and why
>> not? :-(

nix> Yes, indeed. This is unavoidable.

It is so unavoidable that other distributions that use different
package/dependency managers seem to be able to do it, because for
example RPM/Yum can distinguish the operations of mere install
and install-or-upgrade, by looking not just at the base name but
also at the version(s) and the architecture (as well as the
package explicit conflict declaration of course).

>> as 'ia32-libs' is just a compilation of the contents of
>> existing '_x86.deb' packages, with a different, architecture
>> dependent name.

nix> That's the only sane way to do it. That or add a `major
nix> number' field which is, in every way that matters, *part of
nix> the package name*.

That depends on the rather peculiar fantasy that the version(s)
and in particular the architecture are not _already_ part of the
package name.

In a string like "libdb-4.3.28-3_i386.deb" I see a base name,
some versions, and architecture, all as part of the ''package
name''. Package managers that take these into account, not just
the base name, for upgrade/install decisions, do exist and they
are used in major distributions that seem to work fairly well for
most people.

It is of course possible to play ''Humpty Dumpty'' games as to
what it is meant by ''package name''...

[ ... ]

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug