Re: [multiarch] Proposal for *-dev packages
Note: I'm not a developer, I'm just a long-time Debian user and
(non-Debian) software developer subscribed to this list -- if that means
you automatically ignore me, so be it.
There are two things being said here, and they aren't necessarily
contradictory. The first is the argument that being able to
simultaneously install -dev packages from multiple sub-architectures
will make things hugely complicated. The second is the argument that on
an AMD64 system, because the hardware happens to be able to run i386
binaries with no performance penalty, developers *may* want to be able
to build i386 binaries without resorting to a chroot.
Aside from their actual merit let's say that both of these are mostly
true, for the sake of argument.
An alternative no one has mentioned is creating a "pure" AMD64 Debian
arch and adding a suite of i386 cross-development packages to the
distribution. That would go some way towards solving the problem at
hand without making all the Debian developers' lives more difficult, and
give architectures besides AMD64 (IA64 is another notable one where it
might be interesting) the ability to build i386 packages without having
to resort to lots of library and compiler building and installation in
/usr/local/i386-cross (or something similar, which is what I'll probably
have to do if Debian doesn't offer a more convenient solution).
Anyway, I'll go back to lurking now -- in case no one's said it lately,
thanks for all your hard and often underappreciated work to make Debian
the pleasure it is to use and admin. Wish I had time to actually help
you all out more than just cheerleading and making suggestions from the
On Fri, Jan 16, 2004 at 12:43:55PM +0000, Paul Brook wrote:
> 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
> > case?
> 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.
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Anderson MacKay <email@example.com>
Green Hills Software -- Hardware Target Connections