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

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



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.

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

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

> 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?

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

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

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

               Linux.conf.au 2004 -- Because we can.
           http://conf.linux.org.au/ -- Jan 12-17, 2004

Attachment: signature.asc
Description: Digital signature


Reply to: