Re: [multiarch] Proposal for *-dev packages
* 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.
| On Thursday 15 January 2004 11:48 am, Tollef Fog Heen wrote:
| > | Other could do with conflicting -dev packages. But the majority of
| > | people I talked to so far would like to havethem installed in parallel
| > | instead of having to purge and reinstall them each time they compile
| > | for a different bit depth.
| > |
| > | Just consider compiling a benchmark that tests 32 bit and 64 bit
| > | support. That would be hell.
| >
| > 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 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.
| 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.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Reply to: