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

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

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

> On Sun, Jan 11, 2004 at 07:15:59PM +0100, Goswin von Brederlow wrote:
> > > > 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. 
> 
> Only up to a point. Most of this would be automatic from shlibdeps.

Build-Depends don't work by magic and any Depends manualy set in the
control file has to be changed. Someone has to look at every single
control file before it can be build.

Without checking first a lot of package will build but have broken
Depends.

> > 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.
> 
> Docs for zlib1g would still be in /usr/share/doc/zlib1g, docs for lib64z1g
> would be in /usr/share/doc/lib64z1g.

Which is not what you would expect for zlib. If you are unfamiliar
with the renaming scheme of amd64 docs of package (of which you don't
know the deb name) will be hard to find.
 
> > You also get a split for bug reports. 
> 
> We already cope with that; see libc6/libc6.1. Don't think that's a
> problem at all.

Its a nuisance.

> > An error in the libc6 postinst
> > would be reported against libc6 and lib64c6 but both use the same
> > postinst file.
> 
> Yep. *shrug*
> 
> > Renaming gets you into problems with the debian/<package>.something
> > files, 
> 
> It might need some tool support (to interpret Package: libfoo${archid}
> into libfoo-amd64, but still use debian/libfoo.* for everything), but
> that doesn't seem particularly difficult. I might be missing something?

The .dir files could be different while the rest is the same. Its
pretty much a mess.

> > 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
> > bad.
> 
> Yup.
> 
> > > 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. 
> 
> The problem comes when you want to install them at the same time. If
> you're installing two packages with the same name, that's the problem.

But only in dpkg, dselect, apt and aptitude. Thats 4 packages to
change compared to nearly every package.

> > Yes. /usr/share/doc/<pkg>/ gets autorenamed and the most recent
> > version or prominent arch or last installed version gets linked to
> > /usr/share/doc/<pkg>/.
> 
> Auto-renaming is another pretty complicated way of breaking (changing,
> if you prefer) the rules. dpkg-divert can be confusing enough as it is.

Do you know if any package dpkg-diverts files from another package in
/usr/share/doc/?

MfG
        Goswin