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

Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]

Anthony Towns <aj@azure.humbug.org.au> writes:

> On Sun, Jan 11, 2004 at 08:00:36AM +0100, Goswin von Brederlow wrote:
> > Renaming packages would work but causes a lot of work, build-failures
> > and broken packages. So, we asked, why do we have to rename packages
> > in the first place?
> Because a policy of "no two packages with the same name will be installed
> simulataneously; dependencies on a package can be resolved by looking
> at nothing but the name and version" is very simple, useful and effective.
> > Package: libc6          (1)
> > Architecture: i386
> > ABI: strict
> > Version: 3.2.3
> > 
> > Package: libc6          (2)
> > Architecture: i686
> > ABI: strict
> > Version: 3.2.3
> > 
> > Package: libc6          (4)
> > Architecture: amd64
> > ABI: strict
> > Version: 3.2.3
> > 
> > Only one of 1, 2 or 3 can be installed and 3 is the prefered one
> > (highest version). But 4 can be installed alone or in combination with
> > any one of 1, 2 or 3.
> This proposal means you can't look at Packages files alone to work out
> the meaning of dependencies, in the above you have to also know that
> "i686" is a subarch, and "amd64" is distinct from "i386", but compatible.

Yes. But thats pretty much the only way you can merge
binary-i386/i486/i586/i686/amd64 all into one system.

If you just look at one binary-<arch>/Packages file that should still
have the current meaning of dependencies. The amd64 flavour won't have
any iX86 packages in there, only when mixing them the ABI becomes an

> > Ideas, complains, objections?
> Yes; renaming the packages is a _good_ thing; breaking the "one installed

It means you have to adapt 10K packages instead of 1K. Renaming means
every Depends and Build-Depends line has to be looked at manually and
99% have to be adapted. Also people will get confused because packages
will be renamed all of a sudden. E.g. docs for zlib1g will be in
lib64z1g all of a sudden. Doesn't make for an easy read on
Depends/Build-Depends lines.

You also get a split for bug reports. An error in the libc6 postinst
would be reported against libc6 and lib64c6 but both use the same
postinst file.

Renaming gets you into problems with the debian/<package>.something
files, which is why currently there are some evil hacks renaming
packages only at certain points during the creation. Keeping two (or 3
for mips) copies of each debian/<package>.something file is just as

> package, one name" rule is really bad. What does "dpkg -L libc6" do on

The thing is you still have one package, one name. You just have
multiple debs providing different ABIs of the same package. I can just
as well say that renaming libc6 to lib64c6 breaks the one package, one
name rule. One package (libc6) now has two names (libc6 and lib64c6).

> an amd64 system, eg? You're also breaking /var/lib/dpkg/info/<pkg>.*,

Currently the same as on i386. In the future I guess it either shows
the files of both libc6 packages or it fails saying it needs an

As for /var/lib/dpkg/info/<pkg>.* thats dpkg internal and I already
have some code handling that.

> you're breaking the /usr/share/doc/<pkg>/copyright standard, you're
> breaking every assumption we've ever made that's based on that rule.

Yes. /usr/share/doc/<pkg>/ gets autorenamed and the most recent
version or prominent arch or last installed version gets linked to

The linking is only needed when alowing different versions of the same
package with different ABIs to be installed. Otherwise, with the same
version, the files in /usr/share should always be identical or at
least exchangable and could be silently overwritten. I prever linking.

> Cheers,
> aj


Reply to: