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

Re: Summary: dpkg shared / reference counted files and version match



On Sat, 11 Feb 2012 03:28:33 +0200
Riku Voipio <riku.voipio@iki.fi> wrote:

> Package proliferation and duplication of arch-independent data are merely
> effects that happen when packagers workaround the lack of shared identical
> files.

+1

> One solution for the binNMU changelogs and generated docs would be to
> use arch-qualified paths for those files. That is much more lightweight
> solution that arch-qualifying all files, even if identical. 

> On Fri, Feb 10, 2012 at 11:56:20PM +0100, Guillem Jover wrote:
> > For files in M-A:same packages under a pkgname based path, the pkgname
> > should always be arch-qualified with the Debian architecture. Most of
> > these could be handled automatically by debhelper and cdbs, this includes
> > things like:
> > 
> >   /usr/share/doc/pkgname/

So this would be everything handled currently by dh_installdocs &
dh_installexamples ?

> >   /usr/share/bug/pkgname
> >   /usr/share/lintian/overrides/pkgname
> >   /usr/share/mime-info/pkgname.*
> >   /usr/share/menu/pkgname
> >   ...
> 
> I find the requring arch-qualified path for for arch-independent
> data ugly system architecture. But of course the beauty of architecture is in
> the eye of the beholder (and lets not forget that Unix with its worse-is-better
> philosophy[1] was never intended to be architectural masterpiece).
> 
> Personally if leaving out shared files makes you upload multiarch enabled
> dpkg to unstable before sagrada familia is complete, i can live it (cursing
> silently in my room converting packages to the new requirement...). I can
> take the trade-off of having something better-than-current soon over having
> the perfect version in distant future...

If the changes needed in low-level toolchain-related -dev packages like
libc*-dev, linux-libc-dev and libstdc++*-dev are not so onerous for the
relevant maintainers that we can actually get a Multi-Arch
cross-compiler installed, then (as I've said before), we can use
separate build environments per architecture in order to get Multi-Arch
into Wheezy, and I'll live with that. One chroot per cross-architecture
is workable - as long as there is sufficient support to actually get
the cross toolchain installed and operational alongside the native
architecture toolchain.

It's more important that we get something workable into Wheezy than to
have the a broken version in Wheezy and the more elegant solution in
Wheezy+1.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpJ7wXmhZ1ST.pgp
Description: PGP signature


Reply to: