Re: Concerns about AMD64 port
John Goerzen <firstname.lastname@example.org> writes:
> On Thu, Feb 05, 2004 at 09:55:58AM -0500, Stephen Frost wrote:
> > * John Goerzen (email@example.com) wrote:
> > > On the AMD64 Ports page, it says "a pure 64bit port seems to be
> > > academical and of little use." I am totally shocked by that statement.
> > You're not the only one, believe me. I was too, and still don't agree
> > with it.
> Good. :-)
> > > So it seems to me that the great benefit to many people of having a
> > > native 64-bit userland has been sacrificed for the questionable benefit
> > > of being able to run proprietary software without making a chroot. I am
> > > still a little shocked about that.
> > Supporting a 64bit userland is one of the goals, of course.
> You'll forgive me for being fooled by the ports page, I hope :-)
> > 1) RH/SuSe have a /lib with 32bit libraries and a /lib64 with 64bit
> > libraries on their amd64 systems.
> > 2) The FHS (I think?) and/or other standards groups are putting in their
> > standards that the 32bit loader is to be at /lib/ld-linux.so and the
> > 64bit loader at /lib64/ld-linux-amd64.so (or whatever the specific
> > names are).
> > 3) Debian wants to be standards compliant, of course.
> > 4) Installing 64bit libraries to /lib64 is pretty difficult just to
> > begin with and have everything work under Debian with the automated
> > build systems and whatnot.
> Ah ha. That makes some sense at least. And yet, at the same time, how
> are RH and Gentoo doing it?
> (Incidentally, what about /usr/lib?)
> Heck, by modifying autoconf and debhelper to dump libs at the right
> spot, we'd probably get 90% of the packages right off the bat.
I patched autoconf already. Problem are all the rules files that move
files around and associated debhelper tools. For the upstream sources
SuSe and RH already did a lot of patching that can be reused where
needed. But mostly its just setting the libprefix in configure calls
in the rules files to get upstream sources to work.
> > 5) RH/SuSe are (at least trying to) supporting mixed 32/64bit amd64
> > systems, doing it on Debian would be good too.
> > 6) Doing a 64bit-only port *now* and a mixed 32bit/64bit port *later*
> > would make for a very difficult upgrade path (personally I'm inclined
> > to say forget the upgrade path, make a 64bit only port *now* so
> > people have a *useful* 64bit system and do the mixed stuff and tell
> > people they need to reinstall if they want to go to the mixed
> > system, and make it clear up front that if they do use the 64bit only
> > port that they'll have to reinstall later if they want to move to the
> > 32/64bit mixed system).
> Exactly. I agree with that.
> > 7) There's been claims that the RM or the ftp-master or someone wouldn't
> > create the amd64 directory for a 64bit only port. No clue how
> > reliable these are, people couldn't point me to specific messages in
> > archives or anything, or give any better wording/reasoning than what
> > I've said above.
> > If you've got the time/resources to do a 64bit-only port and maintain it
> > and can convince whomever to give you wanna-build access so that you can
> > keep it up with the rest of unstable I'd say go for it. I'd even be
> One does not have to have permission to run an autobuilder; permission
> is only needed if it will be part of the official build infrastructure.
The only thing you realy need is a valid gpg key to upload
packages. But if you just go ahead and add an autobuilder you might
run into social problems.
Since the amd64 port is hosted on alioth you only need alioth access
currently. Till sarge is out of the way that will remain that way.
> As an example, I right now am running an unofficial autobuilder for the
> netbsd-i386 port. I grabbed the source for wanna-build, buildd, and
> sbuild, and installed it on my box. I'm putting my packages up on
> people.debian.org, which has a big disk and fast connection.
I hope we can make this more of a group effort and use a common