On Mon, May 23, 2005 at 07:27:22PM -0700, David S.Miller wrote: > From: Ben Collins <[EMAIL PROTECTED]> > Date: Mon, 23 May 2005 20:21:57 -0400 > > > But (and this but is for David), that means users can't simply do > > "apt-get source foo; cd foo-1.1; dpkg-buildpackage" and get the same build > > they got from us, which is a consistency Debian needs. Maintainers trying > > to fix bugs on sparc in their packages that log in to one of our machines > > shouldn't have to worry about this subtlety either. > > Make the login environment be sparc32 by default. Doesn't that > solve the problem? And for die-hard 64-bit people like me they > can undo this via some configuration mechanism. > > It is one option.
That's probably too ugly for some ppl. Then we'll have to answer the question of "why does my sparc64 uname report sparc?". > Another option is to bite the bullet and think about real sub-arch'ing > for debian packages. Then, for a *.sparc package the dpkg building > knows to "sparc32 whatever", yet for a *.sparc64 package the dpkg > building machinery does not. That's what I've wanted for a long time. There was a proposal a long time ago that looked really nice, but I don't think anyone had the motivation to get it all implemented. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]