Re: [multiarch] Proposal for *-dev packages
On Friday 16 January 2004 11:00 am, Tollef Fog Heen wrote:
> * Paul Brook
> I have a Mail-Followup-To set. Please respect it, or at least respect
> the policy on Debian lists not to Cc the one you are replying to.
Sorry. My mail client (kmail) has obviously never head of that header.
> | > We aren't gentoo. Users aren't supposed to do that, but if they do,
> | > they should use a chroot. Optimize for the common case.
> | I disagree.
> What are you disagreeing with? That we aren't gentoo? That users
> aren't supposed to do that? Or that we should optimize for the common
I don't really see how gentoo is relevant. AFAIK gentoo isn't multiarch, so
any comparisons don't really really seem valid.
My main disagreement was with "users aren't supposed to do that".
I'm also wary of "optimize for the common case", if it penalises a
significant, but maybe slightly less common case.
> | I suspect a good number of Debian users are developers like myself. A
> | multiarch system is IMHO fairly useless if you can only use it to develop
> | software for the 'primary' subarch. This is especially true eg. on mips
> | where preferred subarch depends on the application (n32 for speed vs. n64
> | for address space).
> Why is running pdebuild32 (or whatever it'll be called) so much worse
> than running debuild? Having co- (or tri-) installable -dev packages
> will be very, very tricky and will require you to massively increase
> the number of packages in the archive or break a number of assumptions
> a lot of places in the packaging system.
I was making my point from the view of a general developer who uses a debian
system, not a debian package maintainer. I'd say building debian packages is
a relatively uncommon case, and arguably should be done in a clean chroot
Hopefully it should be possible to implement proper multiarch system without
creating an excessive number of new packages. There have been a number of
suggestions on this list how to do this. Admittedly there are still
unresolved issues with all of these, but noone said making a proper multiarch
system was going to be easy:)
> | Also, providing a multiarch gcc/libc is only of limited use if all the
> | other -dev packages only support a single arch. Reinstalling the -dev
> | package to compile for a different subarch really isn't practical.
> That is why you compile in a chroot. AMD64 systems will have >= 256MB
> RAM and many gigs of HDD space, so this shouldn't be a real problem.
It's not just the disk space requirements. With a chroot you effectively have
two seperate (abeit closely tied) systems to maintain. As a developer this
negates many of the benefits of a multiarch system vs seperate machines.