Re: -= PROPOSAL =- Release sarge with amd64
> | It's fairly simple for the port to be built to support both 32 and 64
> | bit LSB apps, and still allow for migration to multiarch.
On Fri, Jul 16, 2004 at 06:45:17PM +0200, Tollef Fog Heen wrote:
> As others have said -- it's not easy to support both 32 and 64 bit. If
> you want to do that properly, you should implement multiarch.
>
> Please keep migration to multiarch out of the equation -- as long as you
> stay out of /lib/$arch-$os (i[34]86-linux, x86_64-linux), you are fine.
Is it just me or are these two paragraphs contradictory?
Every upgrade up till now has managed to deal with replacing files in
the same directory as what the new package supplies.
What is it about multiarch that makes it such a pancea for the future,
and such a horrible thing to start moving towards?
> | [For example: Have /lib64 be a symlink link to /x86_64-linux/lib and have
> | /lib be a symlink to /i486-linux/lib (similar for /usr/lib*). Make sure
> | that the libraries explicitly mentioned in LSB are installed in the 64
> | bit library, leave the others as known bugs, to be fixed when people have
> | the time and inclination. Make sure your patches respect some env var
> | (perhaps MULTIARCH_HOST), and have that be set at a fairly high level.]
>
> If you're going to do this, then why not do the full multiarch dance?
Because you can't do everything at once.
Also, maybe it's good to keep some distinctions in mind here. There's the
system on which the packages are installed (where lib and lib64 are
symlinks to multiarch lib dirs), and there's the packages themselves
(which install into /lib, /lib64, etc.).
> If you do that, you'll end up with fixing packages once, not twice.
Assuming I make no mistakes, and am capable of fixing everything at the
same time, sure.
I don't know about you, but I'm just not that competent.
> | > Uh, multiarch *will* be painful. biarch *would* have been painful too.
> | > We're not disputing that, that's why we're *NOT* asking for biarch or
> | > multiarch to be part of sarge. Not even close. We're interested in
> | > having pure64 released with sarge so that Debian users can use their
> | > amd64 systems reasonably.
> |
> | In my opinion, the only thing painful about my above example
> | implementation is that it make the things that need to be fixed painfully
> | obvious.
>
> Have you made a biarch package yet? If not, please do that and come
> back when you have. It's painful, to do it the right way.
What do you mean by "the right way"? And, why is that way right?
> | My current objections are that you're not planning for compliance with
> | LSB and you're not planning for migration to multiarch. Both will be
> | a lot easier to achieve with just a little forethought.
> |
> | [Before you explained about multiarch, my only objection was the lack
> | of 32 bit LSB support.]
>
> .. and the multiarch migration is independent of this and will happen
> for all arches, not just multiarch-capable ones. (Because even though
> $random_arch might not be able to run some binaries doesn't mean that
> $some_other_random_arch can't run $random_arch's binaries.)
I've never claimed otherwise.
--
Raul
Reply to: