[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Please test gzip -9n - related to dpkg with multiarch support

On Wed, Feb 08, 2012 at 11:56:06AM -0800, Russ Allbery wrote:
> Riku Voipio <riku.voipio@iki.fi> writes:
> > On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:

> >> The same principle that applies to all dpkg output to avoid ambiguity
> >> would apply everywhere, whenever there's a “Multi-Arch: same” package
> >> name that needs to be unambiguous, it just always gets arch-qualified.
> >> The rest would stay as they are.

> > That is a major waste of space of having multiple copies of identical
> > files with different arch-qualified names. Is that really better
> > architecture to have multiple copies of identical files on user systems?

> Is it really, though?  The files we're talking about are not generally
> large.  I have a hard time seeing a case where the files would be large
> enough to cause any noticable issue and you wouldn't want to move them
> into a separate -common or -doc package anyway.

So I had a look at the Ubuntu archive, which already has a large collection
of packages converted to Multi-Arch: same, to provide some hard facts for
this discussion.

 - 1219 binary packages are marked Multi-Arch: same
 - 2197 files are shipped in /usr/share by these packages, outside of
   /usr/share/doc - which, by and large, are files that can actually be
   shared between architectures.
 - These files are distributed between 47 different subdirectories:
    703 ./usr/share/man
    604 ./usr/share/ada
    187 ./usr/share/lintian
    185 ./usr/share/locale
     93 ./usr/share/alsa
     70 ./usr/share/gtk-doc
     53 ./usr/share/bug
     36 ./usr/share/qt4
     35 ./usr/share/libtool
     22 ./usr/share/themes
     16 ./usr/share/lua
     16 ./usr/share/libphone-ui-shr
     15 ./usr/share/aclocal
     14 ./usr/share/icons
     11 ./usr/share/pam-configs
     11 ./usr/share/info
     10 ./usr/share/vala
      9 ./usr/share/gtk-engines
      8 ./usr/share/qalculate
      8 ./usr/share/OGRE
      7 ./usr/share/xml
      7 ./usr/share/libwacom
      7 ./usr/share/gir-1.0
      7 ./usr/share/dbconfig-common
      6 ./usr/share/mupen64plus
      6 ./usr/share/libgphoto2
      5 ./usr/share/pixmaps
      5 ./usr/share/openchange
      4 ./usr/share/mime-info
      4 ./usr/share/menu
      4 ./usr/share/libofx4
      4 ./usr/share/gstreamer-0.10
      3 ./usr/share/java
      3 ./usr/share/gconf
      3 ./usr/share/gcc-4.6
      3 ./usr/share/applications
      2 ./usr/share/guile
      2 ./usr/share/application-registry
      1 ./usr/share/tdsodbc
      1 ./usr/share/psqlodbc
      1 ./usr/share/pascal
      1 ./usr/share/libpam-ldap
      1 ./usr/share/libmyodbc
      1 ./usr/share/libaudio2
      1 ./usr/share/kde4
      1 ./usr/share/gst-plugins-base
      1 ./usr/share/avahi
 - For many of these files, it would be actively harmful to use
   architecture-qualified filenames.  Manpages included in -dev packages
   should not change names based on the architecture; having
   /usr/share/pam-config contain multiple files for the same profile, one
   for each architecture of the package that's installed, would not work
   correctly; etc.
 - If we needed to split the arch-indep contents out of the M-A: same
   package instead of reference counting in dpkg, that would be roughly 170
   new binary packages.  139 of them would contain 10 files or less
   (exclusive of /usr/share/doc).

I think there are pretty solid benefits to proceeding with a dpkg that
allows sharing files across M-A: same packages.  Even if we decided we
couldn't rely on gzip, there are still lots of other cases where this

And besides, consider that a M-A: same package shipping contents in a
non-architecture-qualified path that vary by architecture is *always* a bug
in that package, which will need to be fixed.  Requiring that M-A: same
packages don't use non-architecture-qualified paths even for files which
*don't* vary by architecture doesn't help much to ensure that we won't have
bugs.  It would be easier for lintian to spot errors in M-A: same packages
if we can say that any file that doesn't have an architecture-qualified path
is buggy, but at this point we already have Jakub's reports anyway, which we
could make a regular part of our archive consistency checks.  So I don't
believe that having dpkg be more strict about files that *could* be shared
will make the user experience any better; it just presents more occasions
for packages to be regarded as buggy and for dpkg to error out.

> foo-config binaries, as opposed to pkg-config files, are indeed going to
> continue to be a problem in model 2, but they're a problem anyway, no?

Yes, they definitely are.

> There's no guarantee that the amd64 and i386 version of a package will
> want the same flags, so we really need some way of having a
> multiarch-aware verson of the -config script.

Preferably by s/foo/pkg/.  pkgconfig gets this right, the standalone tools
all get it wrong, there's no good reason not to just replace them with

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: