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

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.

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

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.

Paul



Reply to: