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
matters.
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
pkgconfig.
--
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