Introduction to multiarch: What maintainers must do

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Hi,

I got some good feedback from my previous Introduction to multiarch
post and some good questions. I'm singling out Manoj Srivastava here
because he was the most recent to ask this on irc but there where
others with the same or simmilar question.

The full multiarch proposal can be read on:
https://wiki.ubuntu.com/MultiarchSpec

Manoj as maintainer wondered what, in a few words, would be involved
in migrating his packages to multiarch. I will use amd64 as example
case but any other multiarch combination works just the same. It
turns out it is more than a few words to spell it all out, on irc is
was just 3 lines. But half the mail are 2 two example patches. So here
we go:

Introduction to multiarch: What maintainers must do
===================================================

To begin with there are 5 cases to consider: (in order of complexity)

1) Architecture: all package
2) Binary package
3) Library package
4) Script interpreter or Service with plugins (and their plugins)
5) none of the above (or I don't care)

For each deb build by your source package you have to decide which of
the 5 cases applies individually. Note that option 5 is safe. You
might hold us all back but you won't break anything.

1) Architecture: all package
----------------------------

You have won. Your package is already multiarch. Hurray.
Now wasn't that easy?

2) Binary package
-----------------

Binary package here means that you package some tool that resides in
[/usr]/[s]bin. For example /bin/sed. Now it does not matter wether sed
is 32bit or 64bit. It also doesn't matter if the program calling sed
is 32bit or 64bit. Now all you need to do is tell dpkg/apt that. You
simply add

Multi-Arch: foreign

in the debian/control stanza for that package and you are done.
Still easy.

3) Library package
------------------

Library packages are slightly more complex, meaning you do have to do
some actual work. Library package mean that you have some shared
library in [/usr]/lib. For example /usr/lib/libz.so.1.2.3.3. Now it
matters wether the library is 32bit or 64bit. Only 32bit binaries can
use the 32bit library and only 64bit binaries can use the 64bit
library. If the user wants to install a 64bit perl but a 32bit mplayer
he will need both the 64bit and 32bit libz.so.1.2.3.3 installed. For
that you need to do 3 things:

a) Follow Policy 8.2 (MUST directive)
No conffiles, no binaries in the library package, no shared files
(/usr/share/doc/package/ is excempt and dpkg will handle that).
Many packages do that already and you should have been doing that
all along.

b) Move the libraries to multiarch dirs
To prevent overwrite conflicts in dpkg the libraries on each
architecture must be in a unique location, namely
[/usr]/lib/$(DEB_HOST_GNU_TYPE). If you do have library support
files then they have to be made not unique as well, e.g. go into
/usr/lib/$(DEB_HOST_GNU_TYPE)/package/.
For most sources that means running
./configure --libdir=/usr/lib/$(DEB_HOST_GNU_TYPE)
or whatever your build system uses to set the library location.
The debian/package.install filles might need to be adjusted to
the new location to or locations used in the rules file itself.

c) Add Multiarch: same

There, that wasn't so bad, was it?

4) Script interpreter or Service with plugins
---------------------------------------------

This is the big scary monster and can't be done in the first round as
it needs some modifications to dpkg to go into a stable release
first. The problem here is that for python scripts it does not matter
wether you have a 32bit or 64bit python. But the 32bit python gtk
bindings only work with a 32bit python. So we have both packages where
the architecture matters and where not.

So for now perl, python, php, ocaml, apache, ... will not be
multiarchified. Packages that depend on any one of those and are not
Architecture: all will be forced to have the same architecture as
perl, python, php, ocaml, apache, ... itself.

If your package is a plugin or language binding then you do nothing.
If your package only contains a script or connects to a service then
pick one of 1-3,5 but leave the "Depends: python" (or whatever it is)
as is.

5) none of the above
--------------------

Nothing above did fit? Multiarch makes no sense for your package?
You have no time to implement those changes?

So you do nothing. Doing nothing is the safe option. Doing nothing
might be perfectly alright. Your package will not be multiarchified.
If that is a hinderance I'm sure someone will beat you with a cluebat
or send you patches. Don't be afraid to ask for help and if you do get
patches welcome them.

Examples (in no way complete) where doing nothing it ok:

The -dev packages will not be multiarchified in the first round. Maybe
not in the second. Only thing you need to do in -dev packages is
adjust the *.so link to match the library package.

Your package is a leaf package or in a small leaf cluster. A leaf
package is a package that nothing depends on. A leaf cluster is a set
of packages where nothing outside the cluster depends on. Doing
nothing means that all packages in that cluster (or the one package Smile

must all come from the same architecture. Changing the architecture of
one means changing it for all. If the cluster is small that won't
hurt. Generally the more (indirect) reverse depends you do have the
more important it is to multiarchify.

Your package might be architecture specific. You can't multiarchify
something that is only available for one architecture.

If your package is priority standard or higher then it probably does
not belong here. But if in doubt wait for someone to ping you or ask.

I hope that helps maintainers to get a glimse of what lies ahead.
Attached are 2 examples of multiarchifying packages: bzip2 and
libselinux.

MfG
Goswin

--- Multiarchifying bzip2 --------------------------------------------
# changelog | 6 ++++++
# control | 2 ++
# rules | 20 ++++++++++----------
# 3 files changed, 18 insertions(+), 10 deletions(-)

diff -u bzip2-1.0.5/debian/changelog bzip2-1.0.5/debian/changelog
--- bzip2-1.0.5/debian/changelog
+++ bzip2-1.0.5/debian/changelog
@@ -1,3 +1,9 @@
+bzip2 (1.0.5-1a0.multi.1) unstable; urgency=low
+
+ * Convert to multiarch
+
+ -- Goswin von Brederlow <goswin-v-b RemoveThis @web.de> Mon, 11 May 2009 02:46:51 +0200
+
bzip2 (1.0.5-1) unstable; urgency=low

* Fix "bzdiff doesn't work if $TMPDIR contains spaces"; closes: #493710
diff -u bzip2-1.0.5/debian/rules bzip2-1.0.5/debian/rules
--- bzip2-1.0.5/debian/rules
+++ bzip2-1.0.5/debian/rules
@@ -152,20 +152,20 @@
### Split

# Development package
- install -d debian/tmp-dev/usr/lib
+ install -d debian/tmp-dev/usr/lib/$(DEB_HOST_GNU_TYPE)
rm debian/tmp/lib/libbz2.so
- ln -s /lib/libbz2.so.1.0 debian/tmp-dev/usr/lib/libbz2.so
- mv debian/tmp/lib/libbz2.a debian/tmp-dev/usr/lib/
+ ln -s /lib/$(DEB_HOST_GNU_TYPE)/libbz2.so.1.0 debian/tmp-dev/usr/lib/$(DEB_HOST_GNU_TYPE)/libbz2.so
+ mv debian/tmp/lib/libbz2.a debian/tmp-dev/usr/lib/$(DEB_HOST_GNU_TYPE)/
mv debian/tmp/include debian/tmp-dev/usr/include

# Library package
- install -d debian/tmp-lib/lib
+ install -d debian/tmp-lib/lib/$(DEB_HOST_GNU_TYPE)
for i in $$(ls debian/tmp/lib/libbz2.so*); do \
- (set -x; echo $$i; mv $$i debian/tmp-lib/lib/); \
+ (set -x; echo $$i; mv $$i debian/tmp-lib/lib/$(DEB_HOST_GNU_TYPE)/); \
done
- ln -s libbz2.so.1.0.4 debian/tmp-lib/lib/libbz2.so.1
- chmod -x debian/tmp-lib/lib/*
+ ln -s libbz2.so.1.0.4 debian/tmp-lib/lib/$(DEB_HOST_GNU_TYPE)/libbz2.so.1
+ chmod -x debian/tmp-lib/lib/$(DEB_HOST_GNU_TYPE)/*

# Binary package
install -d debian/tmp-run
@@ -221,14 +221,14 @@
fi; \
done
$(DEBSTRIP) --strip-unneeded -R .note -R .comment \
- debian/tmp-lib/lib/*.so*
- $(DEBSTRIP) --strip-debug debian/tmp-dev/usr/lib/*.a
+ debian/tmp-lib/lib/$(DEB_HOST_GNU_TYPE)/*.so*
+ $(DEBSTRIP) --strip-debug debian/tmp-dev/usr/lib/$(DEB_HOST_GNU_TYPE)/*.a

# Control files
install -d debian/tmp-{lib,dev,run}/DEBIAN
cp debian/shlibs debian/tmp-lib/DEBIAN/shlibs

- dpkg-shlibdeps debian/tmp-lib/lib/*.so*
+ dpkg-shlibdeps debian/tmp-lib/lib/$(DEB_HOST_GNU_TYPE)/*.so*
dpkg-gencontrol -isp -Pdebian/tmp-lib -plibbz2-1.0
rm debian/substvars
dpkg-gencontrol -isp -Pdebian/tmp-dev -plibbz2-dev
diff -u bzip2-1.0.5/debian/control bzip2-1.0.5/debian/control
--- bzip2-1.0.5/debian/control
+++ bzip2-1.0.5/debian/control
@@ -11,6 +11,7 @@
Priority: important
Section: libs
Architecture: any
+Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: high-quality block-sorting file compressor library - runtime
This package contains libbzip2 which is used by the bzip2 compressor.
@@ -56,6 +57,7 @@
Priority: optional
Section: utils
Architecture: any
+Multi-Arch: foreign
Depends: libbz2-1.0 (=${binary:Version}), ${shlibs:Depends}
Suggests: bzip2-doc
Replaces: libbz2 (<<0.9.5d-3)

--- Multiarchifying libselinux ---------------------------------------
# debian/changelog | 6 ++++++
# debian/control | 2 ++
# debian/local-vars.mk | 2 +-
# debian/local.mk | 6 ++++--
# src/Makefile | 9 +++++----
# 5 files changed, 18 insertions(+), 7 deletions(-)

diff -u libselinux-2.0.71/debian/local.mk libselinux-2.0.71/debian/local.mk
--- libselinux-2.0.71/debian/local.mk
+++ libselinux-2.0.71/debian/local.mk
@@ -15,6 +15,8 @@
##
###############################################################################

+export DEB_HOST_GNU_TYPE
+
testdir:
$(testdir)

@@ -124,8 +126,8 @@
$(MAKE) DESTDIR=$(TMPTOP) -C include install
$(MAKE) DESTDIR=$(TMPTOP) -C src install
rm -fr $(LIBDIR)
- rm -f $(TMPTOP)/usr/lib/libselinux.so
- ln -s /lib/libselinux.so.1 $(TMPTOP)/usr/lib/libselinux.so
+ rm -f $(TMPTOP)/usr/lib/$(DEB_HOST_GNU_TYPE)/libselinux.so
+ ln -s /lib/$(DEB_HOST_GNU_TYPE)/libselinux.so.1 $(TMPTOP)/usr/lib/$(DEB_HOST_GNU_TYPE)/libselinux.so
rm -rf $(TMPTOP)/usr/lib/python2.4/
$(install_file) debian/changelog $(DOCDIR)/changelog.Debian
$(install_file) ChangeLog $(DOCDIR)/changelog
diff -u libselinux-2.0.71/debian/changelog libselinux-2.0.71/debian/changelog
--- libselinux-2.0.71/debian/changelog
+++ libselinux-2.0.71/debian/changelog
@@ -1,3 +1,9 @@
+libselinux (2.0.71-1a0.multi.1) unstable; urgency=low
+
+ * Convert to multiarch
+
+ -- Goswin von Brederlow <goswin-v-b RemoveThis @web.de> Mon, 11 May 2009 09:30:29 +0200
+
libselinux (2.0.71-1) unstable; urgency=low

* New upstream release
diff -u libselinux-2.0.71/debian/local-vars.mk libselinux-2.0.71/debian/local-vars.mk
--- libselinux-2.0.71/debian/local-vars.mk
+++ libselinux-2.0.71/debian/local-vars.mk
@@ -27,7 +27,7 @@

PREFIX = /usr
BINDIR = $(TMPTOP)$(PREFIX)/bin
-LIBDIR = $(TMPTOP)/lib
+LIBDIR = $(TMPTOP)/lib/$(DEB_HOST_GNU_TYPE)
INCLUDE = $(TMPTOP)$(PREFIX)/include
INCDIR = $(INCLUDE)/selinux

diff -u libselinux-2.0.71/debian/control libselinux-2.0.71/debian/control
--- libselinux-2.0.71/debian/control
+++ libselinux-2.0.71/debian/control
@@ -10,6 +10,7 @@

Package: selinux-utils
Architecture: any
+Multi-Arch: foreign
Section: admin
Depends: ${shlibs:Depends}
Description: SELinux utility programs
@@ -22,6 +23,7 @@

Package: libselinux1
Architecture: any
+Multi-Arch: same
Section: libs
Priority: required
Depends: ${shlibs:Depends}
diff -u libselinux-2.0.71/src/Makefile libselinux-2.0.71/src/Makefile
--- libselinux-2.0.71/src/Makefile
+++ libselinux-2.0.71/src/Makefile
@@ -1,7 +1,7 @@
# Installation directories.
PREFIX ?= /usr
-LIBDIR ?= $(PREFIX)/lib
-SHLIBDIR ?= $(DESTDIR)/lib
+LIBDIR ?= $(PREFIX)/lib/$(DEB_HOST_GNU_TYPE)
+SHLIBDIR ?= $(DESTDIR)/lib/$(DEB_HOST_GNU_TYPE)
INCLUDEDIR ?= $(PREFIX)/include
PYLIBVER ?= $(shell python -c 'import sys;print "python%d.%d" % sys.version_info[0:2]')
PYINC ?= /usr/include/$(PYLIBVER)
@@ -9,8 +9,9 @@
PYTHONLIBDIR ?= $(LIBDIR)/$(PYLIBVER)
RUBYLIBVER ?= $(shell ruby -e 'print RUBY_VERSION.split(".")[0..1].join(".")')
RUBYPLATFORM ?= $(shell ruby -e 'print RUBY_PLATFORM')
-RUBYINC ?= $(LIBDIR)/ruby/$(RUBYLIBVER)/$(RUBYPLATFORM)
-RUBYINSTALL ?= $(LIBDIR)/ruby/site_ruby/$(RUBYLIBVER)/$(RUBYPLATFORM)
+RUBYLIB ?= $(PREFIX)/lib/ruby
+RUBYINC ?= $(RUBYLIB)/$(RUBYLIBVER)/$(RUBYPLATFORM)
+RUBYINSTALL ?= $(RUBYLIB)/site_ruby/$(RUBYLIBVER)/$(RUBYPLATFORM)

LIBVERSION = 1

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Hi,

small add on.

Any package in debian can be multiarchified at any time. You do not
have to wait for all your depends to be multiarchified or notifiy your
reverse depends when you are ready. The state of your depends will
only matter when someone actualy does a multiarch installation and
apt/dpkg will figure out by themself if all the depends are ready or
not. The current apt/dpkg will just ignore the multiarchifying.

Multiarchifying your package does not hurt the installability in any
way. It can only help.

MfG
Goswin

PS: If every DD would patch one package we would be way past the "99%
of all users are happy" goal. The norml use set of libraries for
32/64bit is about 150 library packages (less source packages).

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Manoj Srivastava · External Since: Dec 07, 2004 Posts: 761

On Wed, Jul 29 2009, Goswin von Brederlow wrote:

> Hi,
>
> small add on.
>
> Any package in debian can be multiarchified at any time. You do not
> have to wait for all your depends to be multiarchified or notifiy your
> reverse depends when you are ready. The state of your depends will
> only matter when someone actualy does a multiarch installation and
> apt/dpkg will figure out by themself if all the depends are ready or
> not. The current apt/dpkg will just ignore the multiarchifying.
>
> Multiarchifying your package does not hurt the installability in any
> way. It can only help.

My first thought was "Err. Won't moving all the shared libs into
a different location kinda screw things up?" And then I looked, and
found

,----
| ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
| # Multiarch support
| /lib/x86_64-linux-gnu
| /usr/lib/x86_64-linux-gnu
| __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
| libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
`----

manoj
--
"Luke, I'm yer father, eh. Come over to the dark side, you hoser." Dave
Thomas, "Strange Brew"
Manoj Srivastava <srivasta.TakeThisOut@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Peter Samuelson · External Since: Mar 29, 2005 Posts: 52

Thanks for this excellent post, Goswin.

[Goswin von Brederlow]
> 3) Library package
> ------------------
>
> a) Follow Policy 8.2 (MUST directive)
> No conffiles, no binaries in the library package, no shared files
> (/usr/share/doc/package/ is excempt and dpkg will handle that).

Policy does not forbid /usr/share/locale/*/LC_MESSAGES/libfoo0.mo (as
it is specific to the soname) - but it sounds like that will break
library multiarch too. Can we have an exception for this? It seems
silly to require a libfoo0-l10n package for every localized library.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Manoj Srivastava <srivasta RemoveThis @debian.org> writes:

> On Wed, Jul 29 2009, Goswin von Brederlow wrote:
>
>> Hi,
>>
>> small add on.
>>
>> Any package in debian can be multiarchified at any time. You do not
>> have to wait for all your depends to be multiarchified or notifiy your
>> reverse depends when you are ready. The state of your depends will
>> only matter when someone actualy does a multiarch installation and
>> apt/dpkg will figure out by themself if all the depends are ready or
>> not. The current apt/dpkg will just ignore the multiarchifying.
>>
>> Multiarchifying your package does not hurt the installability in any
>> way. It can only help.
>
> My first thought was "Err. Won't moving all the shared libs into
> a different location kinda screw things up?" And then I looked, and
> found
>
> ,----
> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
> | # Multiarch support
> | /lib/x86_64-linux-gnu
> | /usr/lib/x86_64-linux-gnu
> | __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> | libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> `----
>
>
> manoj

Runtime support has been there a long time. Even sarge I think.

# ldconfig -v | grep /
/usr/lib/i486-linux-gnu:
/usr/local/lib:
/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu:
/lib:
/lib32:
/usr/lib:
/usr/lib32:
/usr/lib/i486-linux-gnu/i686: (hwcap: 0x0008000000000000)
/usr/lib/tls: (hwcap: 0x8000000000000000)
/usr/lib32/i486: (hwcap: 0x0002000000000000)
/usr/lib32/i686: (hwcap: 0x0008000000000000)
/usr/lib32/i586: (hwcap: 0x0004000000000000)
/usr/lib/i486-linux-gnu/i686/cmov: (hwcap: 0x0008000000008000)
/usr/lib32/i686/cmov: (hwcap: 0x0008000000008000)

Even hwcaps function within multiarch dirs.

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Steve Langasek · External Since: Dec 13, 2004 Posts: 2140

On Wed, Jul 29, 2009 at 11:53:37AM -0500, Peter Samuelson wrote:

> Thanks for this excellent post, Goswin.

> [Goswin von Brederlow]
> > 3) Library package
> > ------------------
> >
> > a) Follow Policy 8.2 (MUST directive)
> > No conffiles, no binaries in the library package, no shared files
> > (/usr/share/doc/package/ is excempt and dpkg will handle that).

> Policy does not forbid /usr/share/locale/*/LC_MESSAGES/libfoo0.mo (as
> it is specific to the soname) - but it sounds like that will break
> library multiarch too. Can we have an exception for this? It seems
> silly to require a libfoo0-l10n package for every localized library.

No exception is needed. The current proposed multiarch design doesn't
prohibit /usr/share/locale* files in library packages; the only requirement
is that any files shipped there are identical between packages of the same
version for multiple architectures.

--
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.DeleteThis@ubuntu.com vorlon.DeleteThis@debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Samuel Thibault · External Since: May 08, 2009 Posts: 47

Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
> the only requirement is that any files shipped there are identical
> between packages of the same version for multiple architectures.

That's however not true for .mo files, for endianness, typically.

Samuel

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Henning Glawe · External Since: Jul 22, 2004 Posts: 27

On Wed, Jul 29, 2009 at 11:09:32AM -0500, Manoj Srivastava wrote:
> My first thought was "Err. Won't moving all the shared libs into
> a different location kinda screw things up?" And then I looked, and
> found
>
> ,----
> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
> | # Multiarch support
> | /lib/x86_64-linux-gnu
> | /usr/lib/x86_64-linux-gnu
> | __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> | libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> `----

side remark: somehow I miss /usr/local/lib/x86_64-linux-gnu in this list; is
this intentionally excluded or simply forgotten?

--
c u
henning

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Peter Samuelson · External Since: Mar 29, 2005 Posts: 52

> Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
> > the only requirement is that any files shipped there are identical
> > between packages of the same version for multiple architectures.

[Samuel Thibault]
> That's however not true for .mo files, for endianness, typically.

So what does this mean for /usr/share/locale and multiarch? Do we need
to move to /usr/lib/{gnu-type}/locale?
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Steve Langasek · External Since: Dec 13, 2004 Posts: 2140

On Wed, Jul 29, 2009 at 01:41:20PM -0500, Peter Samuelson wrote:

> > Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
> > > the only requirement is that any files shipped there are identical
> > > between packages of the same version for multiple architectures.

> [Samuel Thibault]
> > That's however not true for .mo files, for endianness, typically.

> So what does this mean for /usr/share/locale and multiarch? Do we need
> to move to /usr/lib/{gnu-type}/locale?

My understanding is that .mo files include an endianness tag, so files of
either endianness can be loaded on any system. It might be simpler to pick
a format to use for multiarch packages, so that these can continue to be
shipped in the library package.

--
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.RemoveThis@ubuntu.com vorlon.RemoveThis@debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Steve Langasek · External Since: Dec 13, 2004 Posts: 2140

Hi Eugene,

On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:

> Moreover, this is not the only exception. Thousands of desktop and server
> packages that contains executable binaries (applications) compiled from
> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too.

First, why do these packages need to be cross-installed? If they don't need
to be, then there's no reason to set the Multi-Arch field on them at all.

Second, why does the Multi-Arch: allowed option not implement what you need?

It seems ok to me if Multi-Arch: allowed eventually becomes the dominant use
case. But there aren't thousands of packages in Debian with "-dbg"
reverse-dependencies, anyway, so this seems to be a complete non-issue in
the short term.

--
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 DeleteThis @ubuntu.com vorlon DeleteThis @debian.org

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Samuel Thibault · External Since: May 08, 2009 Posts: 47

Peter Samuelson, le Wed 29 Jul 2009 13:41:20 -0500, a écrit :
>
> > Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
> > > the only requirement is that any files shipped there are identical
> > > between packages of the same version for multiple architectures.
>
> [Samuel Thibault]
> > That's however not true for .mo files, for endianness, typically.

Mmm, on second though, maybe not, as I can find quite a few arch:all
packages containing them. I now remember some thread about that on
debian-devel.

Samuel

--
To UNSUBSCRIBE, email to debian-devel-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Russ Allbery · External Since: Nov 17, 2005 Posts: 897

Samuel Thibault <sthibault.TakeThisOut@debian.org> writes:
> Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :

>> the only requirement is that any files shipped there are identical
>> between packages of the same version for multiple architectures.
>
> That's however not true for .mo files, for endianness, typically.

However, you *can* share the same .mo files on each platform, since the
gettext code copes with endianness issues at runtime if need be.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Discussions should probably go to debian-dpkg.

"Eugene V. Lyubimkin" <jackyf.devel DeleteThis @gmail.com> writes:

> Hi Goswin, hi -devel,
>
> I would somewhat object to Multi-Arch field in the long run, and here are my
> thoughts.
>
> What the multiarch spec proposes now is package-oriented approach: the package
> should define whether it is 'same' or 'foreign' kind. This is not
> straightforward, because in fact not the package decides it's multiarch
> 'role', but its reverse dependencies. Only they 'decide' they want to
> arch-dependent package 'functionality' or arch-independent one. From the
> package manager PoV (dpkg and its frontends) I find dependency-oriented
> multiarch info is more clearer and easier to implement.

For most things the depended on package decided what its interface
is. Wether it provides a command line interface (sed) or a binary
interface (libfoo.so.X) to the world. This is usually clear cut.

The reason why we want to define this in the depended on package is
threefold:

1) Many packages depend on a few libraries. If we tag the few
libraries all the depending packages become installable. Less work.

2) Tagging package relationships instead of packages means extending
the syntax of package relationsships, trusting the binary packages to
get the depends right (and those are manual depends apart from libs)
and making package relationships in every package longer. Packages
files are HUGE already:
-rw-r--r-- 1 root root 27M Jul 24 18:35 /var/lib/apt/lists/chocos_debian_dists_sid_main_binary-amd64_Packages

3) 3rd party packages are verry hard to change. Lets face it, on amd64
a major reason for doing this is to get those 3rd party products
running that still haven't managed to build 64bit versions. Getting
them to tag their packages and tag them right would take forever. It
is way to easy for them to tag something wrong.

But there is another reason, a reason why we must:

A library package must say if it is coinstallable for multiple
architectures or not. Must say if it was multiarchified or not. Just
because some package depends on a libary with some "same architecture"
flags in no way means that library is multiarchified. So we need every
library package to say "Multi-Arch: same" when it has moved its
library files to /usr/lib/$(DEB_HOST_GNU_TYPE). Why should we not use
that information also for package relationships as well? Adding the
"same" flag in both the library and the depends seems stupid.

Without the flag in each library it would be way to easy for packages
to screw the system and multiarchifying would have to be in strict
order of dependencies, with lots of transitions and lots of versioned
depends and so on. Verry ugly.

And if we have "Multi-Arch: same" then also doing "Multi-Arch:
foreign" seems logical. No point in manually flagging package
relationships on binaries but autodetect package relationships on
libraries. I rather flag one binary package than 500 reverse depends
on it. The problem cases really are the exception (ignoring the -dbg
packages below, that should use magic in the package managers). A mere
handfull out of 20k packages.

> Goswin, as you are already noted, the packages which are known to have both
> kind of dependencies - at least, some interpreters - have nothing to do with
> that Multi-Arch field, and to handle them, you'll have to put this info in the
> package that is dependent on this interpreter in the long run.
>
> Moreover, this is not the only exception. Thousands of desktop and server
> packages that contains executable binaries (applications) compiled from
> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too. With
> 'arch:all' packages being not a problem at all fortunately, there are only one
> (?) kind of packages left with meaningful Multi-Arch fields - arch-dependent
> library packages for compiled languages which are always multiarch 'same', but
> they also already special-cased/handled by various tools like dpkg-shlibdeps,
> dpkg-genshlibs, and it would been possible to even generate runtime
> dependencies ({shlibs:Depends}) with proper multiarch dependency info without
> even bothering the maintainer to do it.

You raise an interesting point there with -dbg packages. Esspecially
considering the Google SoC project that wants to automatically build
-dbg packages for everything in debian. Those .ddeb packages. Too me
it seems that .ddeb packages seem like a really good idea and teaching
the package management system that .ddeb packages must match the
architecture no matter what the .deb says seems like the solution to
your example. The -dbg packages could be handled all in one go
magically. So do you have another example besides -dbg packages?

I myself am not yet happy with the "Multi-Arch: allowed" feature as
solution. And I haven't heard all the rational behind it. Why it is
better than other suggestions from the past. It is something that has
been added to the specs recently and I think you make a point that
maybe it needs to be thought of or explained some more. The existing
-dbg packages certainly make a point for allowing "Depends: foo:same"
or "Depends: foo:arch" no matter what foo has as "Multi-Arch: ...".

Or maybe -dbg could say "Multi-Arch: force-depends" overriding what
the depended on package says. The advantage of the last would be that
it would not require a dpkg transition. But it only works well with
-dbg packages as they only depend on exactly their striped counterpart.

Another option would be for foo to
Provides: foo-$(DEB_HOST_GNU_TYPE)-${binary:version}
and for foo-dbg to depend on that. Or for plugins
Provides: foo-$(DEB_HOST_GNU_TYPE)-$(PLUGIN_ABI).

So maybe back to the drawing board for "Multi-Arch: allowed"?

Note that for current use cases, things people use biarch for, there
is I think only pam, pango, gtk and qt with plugin issues. All of
those are libraries and will have "Multi-Arch: same". I agree the -dbg
packages have to be handled in some way in the first round. Doesn't
have to be the final way, just has to prevent breaking things. But
delaying the rest of problem packages to work multiarchified to a
second round after a stable release would still allow 99% of use cases
to be happy. So lets do this in increments.

> For the upgrade path, we can stick default multiarch 'same' to the all
> packages in archive, so implementing multiarch support won't broke anything at
> all at all without changing nor source not binary packages at this moment, and
> the maintainers are free to bother ourselves to mark some dependencies as
> multiarch 'same' to allow foreign dependencies to be satisfied with less
> number of packages in the system in the long run.

Arch: all packages are considered "foreign" and I think you ment
that. Arch: all packages are considered to be really for all
architectures when it comes to installing. Although that is not true
for the sake of package relationships when you look at it
recursively. Look at transitional dummy packages. Consider
"libfoo1:all depends libbar2:any" and "baz:all depends buzz:any" (buzz
being a binary). libbar2 must have the same arch but buzz can have any
arch for packages depending on libfoo1 and baz.

But that is something for the implementation in dpkg/apt and not
something maintainers have to worry about. dpkg and apt will sort out
Arch: all packages automatically.

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Henning Glawe <glaweh.DeleteThis@debian.org> writes:

> On Wed, Jul 29, 2009 at 11:09:32AM -0500, Manoj Srivastava wrote:
>> My first thought was "Err. Won't moving all the shared libs into
>> a different location kinda screw things up?" And then I looked, and
>> found
>>
>> ,----
>> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
>> | # Multiarch support
>> | /lib/x86_64-linux-gnu
>> | /usr/lib/x86_64-linux-gnu
>> | __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
>> | libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
>> `----
>
> side remark: somehow I miss /usr/local/lib/x86_64-linux-gnu in this list; is
> this intentionally excluded or simply forgotten?

--- libc6: /etc/ld.so.conf.d/libc.conf -------------------------------
# libc default configuration
/usr/local/lib

So where do we put /usr/local/lib/x86_64-linux-gnu now?

Eglibc maintainers, what do you think?

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Steve Langasek <vorlon.TakeThisOut@debian.org> writes:

> Hi Eugene,
>
> On Wed, Jul 29, 2009 at 09:34:42PM +0300, Eugene V. Lyubimkin wrote:
>
>> Moreover, this is not the only exception. Thousands of desktop and server
>> packages that contains executable binaries (applications) compiled from
>> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
>> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too.
>
> First, why do these packages need to be cross-installed? If they don't need
> to be, then there's no reason to set the Multi-Arch field on them at all.

I want zsh for be "Multi-Arch: foreign" so zomg:i386 and
flowscan:amd64 can be installed. But then zsh:amd64 and zsh-dbg:i386
would be installable, which clearly does not give functional debugging
symbols.

-dbg packages are a valid concern I think. But not a show stopper. One
that can be solved with a bit of magic. .ddeb packages would be a
solution benefiting users, multiarch and the archive and mirrors in
the long run. Till then -dbg packages can be detected by name in the
worst case.

> Second, why does the Multi-Arch: allowed option not implement what you need?
>
> It seems ok to me if Multi-Arch: allowed eventually becomes the dominant use
> case. But there aren't thousands of packages in Debian with "-dbg"
> reverse-dependencies, anyway, so this seems to be a complete non-issue in
> the short term.

% apt-cache search -- -dbg | wc -l
920

Approaching *1* thousands of packages. Smile

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

Hi gettext,

while talking about multiarch the issue was raised that

/usr/share/locale/*/*package.mo

is not identical across all architectures as multiarch would require.

Russ Allbery <rra.DeleteThis@debian.org> writes:

> Samuel Thibault <sthibault.DeleteThis@debian.org> writes:
>> Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit :
>
>>> the only requirement is that any files shipped there are identical

there == /usr/share/

>>> between packages of the same version for multiple architectures.
>>
>> That's however not true for .mo files, for endianness, typically.
>
> However, you *can* share the same .mo files on each platform, since the
> gettext code copes with endianness issues at runtime if need be.

So we would have to define a default endianness for creating such
files. A patch to gettext to create them allways little endian (or the
other way) seems in order.

Thoughts from the maintainer?

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Aurelien Jarno · External Since: Nov 08, 2004 Posts: 527

On Wed, Jul 29, 2009 at 11:33:51PM +0200, Goswin von Brederlow wrote:
> Henning Glawe <glaweh DeleteThis @debian.org> writes:
>
> > On Wed, Jul 29, 2009 at 11:09:32AM -0500, Manoj Srivastava wrote:
> >> My first thought was "Err. Won't moving all the shared libs into
> >> a different location kinda screw things up?" And then I looked, and
> >> found
> >>
> >> ,----
> >> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
> >> | # Multiarch support
> >> | /lib/x86_64-linux-gnu
> >> | /usr/lib/x86_64-linux-gnu
> >> | __> dlocate /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> >> | libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> >> `----
> >
> > side remark: somehow I miss /usr/local/lib/x86_64-linux-gnu in this list; is
> > this intentionally excluded or simply forgotten?
>
> --- libc6: /etc/ld.so.conf.d/libc.conf -------------------------------
> # libc default configuration
> /usr/local/lib
>
> So where do we put /usr/local/lib/x86_64-linux-gnu now?
>
> Eglibc maintainers, what do you think?
>

We should add a config file for that, haven't think more about the
details.

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien DeleteThis @aurel32.net http://www.aurel32.net

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Goswin von Brederlow · External Since: Feb 09, 2009 Posts: 90

"Eugene V. Lyubimkin" <jackyf.devel DeleteThis @gmail.com> writes:

> Goswin von Brederlow wrote:
>> "Eugene V. Lyubimkin" <jackyf.devel DeleteThis @gmail.com> writes:
>>> What the multiarch spec proposes now is package-oriented approach: the package
>>> should define whether it is 'same' or 'foreign' kind. This is not
>>> straightforward, because in fact not the package decides it's multiarch
>>> 'role', but its reverse dependencies. Only they 'decide' they want to
>>> arch-dependent package 'functionality' or arch-independent one. From the
>>> package manager PoV (dpkg and its frontends) I find dependency-oriented
>>> multiarch info is more clearer and easier to implement.
>>
>> For most things the depended on package decided what its interface
>> is. Wether it provides a command line interface (sed) or a binary
>> interface (libfoo.so.X) to the world. This is usually clear cut.
> Hm, no, not for all. Again, amarok-dbg depends on amarok in arch-dependent
> way. And some others. Yes, no one provided sed-dbg yet Smile

<self>-dbg is not the world. Smile

>> The reason why we want to define this in the depended on package is
>> threefold:
>>
>> 1) Many packages depend on a few libraries. If we tag the few
>> libraries all the depending packages become installable. Less work.
> Keeping existing relationships with existing syntax as 'multiarch:same' become
> installable all packages. Without any work. Well, with all the dependency
> tree, but for that libraries it's anyway the same case.

No, that just plain makes every package cause an override
conflict. That is the difference between no Multi-Arch field and
same. Same means packages are coinstallable. Apart from that no
Multi-Arch and same behave the same.

The Multi-Arch: same actualy is an improvement to your
suggestion. YOur suggestion is already in the specs for when no
Multi-Arch is specified.

>> 2) Tagging package relationships instead of packages means extending
>> the syntax of package relationsships, trusting the binary packages to
>> get the depends right
> You'll have to do it sooner or later. At least for already mentioned perl,
> python and others. Or no?

Yes, but how many are there. Perl for example has 2627 reverse
depends. How many of those are plugins?

>> and making package relationships in every package longer. Packages
>> files are HUGE already:
>> -rw-r--r-- 1 root root 27M Jul 24 18:35 /var/lib/apt/lists/chocos_debian_dists_sid_main_binary-amd64_Packages
> Well, "Multi-Arch: <value>" would also make Packages longer.

But only one entry per package, not one entry per package
relation. Say a library has only 2 reverse depends. Tagging both with
":kfreebsd-amd64" will be longer than "Multi-Arch: same". And
libraries and binaries have a lot more reverse depends.

>> 3) 3rd party packages are verry hard to change. Lets face it, on amd64
>> a major reason for doing this is to get those 3rd party products
>> running that still haven't managed to build 64bit versions. Getting
>> them to tag their packages and tag them right would take forever. It
>> is way to easy for them to tag something wrong.
> Same answer as for 1).

No. Most 3rd party debs are leaf packages/cluster. Nothing needs to
happen there. Imagine packages as a tree sorted by dependencies. We
only need to tag the root but the far bigger crown can stay as
is. As mentioned before there are less than 200 packages in use in
biarch now.

>> But there is another reason, a reason why we must:
>>
>> A library package must say if it is coinstallable for multiple
>> architectures or not. Must say if it was multiarchified or not. Just
>> because some package depends on a libary with some "same architecture"
>> flags in no way means that library is multiarchified. So we need every
>> library package to say "Multi-Arch: same" when it has moved its
>> library files to /usr/lib/$(DEB_HOST_GNU_TYPE). Why should we not use
>> that information also for package relationships as well?
> Because, hm, this is different kind of info.
>
>> Adding the
>> "same" flag in both the library and the depends seems stupid.
> Got it. I would still propose 'Multi-Arch: yes' only for mentioned purposes
> (co-installability) and dependencies for others. But yes, this makes my point
> more weak.

Yeah, the earlier drafts did have yes/no but at that meeting the Ubuntu
draft was worded they somehow decided on same/foreign.

>> on it. The problem cases really are the exception (ignoring the -dbg
>> packages below, that should use magic in the package managers
> mm? is it a part of a plan? urh, ugly

Not yet.

>>> Goswin, as you are already noted, the packages which are known to have both
>>> kind of dependencies - at least, some interpreters - have nothing to do with
>>> that Multi-Arch field, and to handle them, you'll have to put this info in the
>>> package that is dependent on this interpreter in the long run.
>>>
>>> Moreover, this is not the only exception. Thousands of desktop and server
>>> packages that contains executable binaries (applications) compiled from
>>> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
>>> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too. With
>>> 'arch:all' packages being not a problem at all fortunately, there are only one
>>> (?) kind of packages left with meaningful Multi-Arch fields - arch-dependent
>>> library packages for compiled languages which are always multiarch 'same', but
>>> they also already special-cased/handled by various tools like dpkg-shlibdeps,
>>> dpkg-genshlibs, and it would been possible to even generate runtime
>>> dependencies ({shlibs:Depends}) with proper multiarch dependency info without
>>> even bothering the maintainer to do it.
>>
>> You raise an interesting point there with -dbg packages. Esspecially
>> considering the Google SoC project that wants to automatically build
>> -dbg packages for everything in debian. Those .ddeb packages. Too me
>> it seems that .ddeb packages seem like a really good idea and teaching
>> the package management system that .ddeb packages must match the
>> architecture no matter what the .deb says seems like the solution to
>> your example. The -dbg packages could be handled all in one go
>> magically. So do you have another example besides -dbg packages?
> No, I noted all examples came to my find for now. I supposed that so major
> architecture change should care about every and all packages.

Only in the sense that multiarch will not allow you to install
something that doesn't work. Esspecially in the first round it is
perfectly fine if some things are not installable in all configuration
as long as they are installable with only native packages. The -dev
packages will fall under that group in an effort to keep the first
round small.

>> I myself am not yet happy with the "Multi-Arch: allowed" feature as
>> solution. And I haven't heard all the rational behind it. Why it is
>> better than other suggestions from the past. It is something that has
>> been added to the specs recently and I think you make a point that
>> maybe it needs to be thought of or explained some more. The existing
>> -dbg packages certainly make a point for allowing "Depends: foo:same"
>> or "Depends: foo:arch" no matter what foo has as "Multi-Arch: ...".
>>
>> Or maybe -dbg could say "Multi-Arch: force-depends" overriding what
>> the depended on package says. The advantage of the last would be that
>> it would not require a dpkg transition. But it only works well with
>> -dbg packages as they only depend on exactly their striped counterpart.
>>
>> Another option would be for foo to
>> Provides: foo-$(DEB_HOST_GNU_TYPE)-${binary:version}
>> and for foo-dbg to depend on that. Or for plugins
>> Provides: foo-$(DEB_HOST_GNU_TYPE)-$(PLUGIN_ABI).
>>
>> So maybe back to the drawing board for "Multi-Arch: allowed"?
>>
>>
>> Note that for current use cases, things people use biarch for, there
>> is I think only pam, pango, gtk and qt with plugin issues. All of
>> those are libraries and will have "Multi-Arch: same". I agree the -dbg
>> packages have to be handled in some way in the first round. Doesn't
>> have to be the final way, just has to prevent breaking things. But
>> delaying the rest of problem packages to work multiarchified to a
>> second round after a stable release would still allow 99% of use cases
>> to be happy. So lets do this in increments.
>>
>>> For the upgrade path, we can stick default multiarch 'same' to the all
>>> packages in archive, so implementing multiarch support won't broke anything at
>>> all at all without changing nor source not binary packages at this moment, and
>>> the maintainers are free to bother ourselves to mark some dependencies as
>>> multiarch 'same' to allow foreign dependencies to be satisfied with less
> ^^^^ here should be 'foreign', of course
>>> number of packages in the system in the long run.
>>
>> Arch: all packages are considered "foreign" and I think you ment
>> that. Arch: all packages are considered to be really for all
>> architectures when it comes to installing. Although that is not true
>> for the sake of package relationships when you look at it
>> recursively. Look at transitional dummy packages. Consider
>> "libfoo1:all depends libbar2:any" and "baz:all depends buzz:any" (buzz
>> being a binary). libbar2 must have the same arch but buzz can have any
>> arch for packages depending on libfoo1 and baz.
> I assume the correct approach would be "libfoo1:all depends libbar2:same" then
> in my view. But must I admit I'm a bit lost with current mixed proposal and
> find it not very intuitive.

I did draw some graphs about all the different package relationships
because I couldn't keep them all straight myself. Unfortunaetly I was
traveling and my battery was dead so I did it on dead wood. I guess I
should transefere them to bits and ask them to be included in the
proposal.

>> But that is something for the implementation in dpkg/apt and not
>> something maintainers have to worry about. dpkg and apt will sort out
>> Arch: all packages automatically.
> I will have to implement this in libcupt too when it's get accepted, so I'm
> also interested.

Then you will also have to deal with all the implicit conflicts and
replaces. E.g. foo:all conflicts/replaces with any foo:<arch>.

Yeah, time to input the graphs I did. Much easier to see this in a
picture.

MfG
Goswin

--
To UNSUBSCRIBE, email to debian-devel-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org

Peter Samuelson · External Since: Mar 29, 2005 Posts: 52

[Goswin von Brederlow]
> 3) Library package
> ------------------
>
> a) Follow Policy 8.2 (MUST directive)
> No conffiles, no binaries in the library package, no shared files
> (/usr/share/doc/package/ is excempt and dpkg will handle that).

We have mostly settled the /usr/share/locale question, and apparently
/usr/share/doc is a special exception anyway....

But in case you need to install other stuff to /usr/share from a
library package: note that anything you compress with gzip, you should
use -n, so you'll get the same bits on every build. And obviously
think about the same issues for other "generated" files in /usr/share.

I suppose /usr/share in library packages is fairly rare anyway.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org