Re: -= PROPOSAL =- Release sarge with amd64
* Raul Miller
| > | 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?
They're not.
| Every upgrade up till now has managed to deal with replacing files in
| the same directory as what the new package supplies.
Uhm, which of the two glibc packages are you talking about? libc6:amd64
or libc6:i386? For them to be coinstallable, they need to have no file
overlaps.
| What is it about multiarch that makes it such a pancea for the future,
| and such a horrible thing to start moving towards?
It will probably cause some instability which we _really_ don't need
when we're trying to get sarge out the door. Our core tools need fixing
for multiarch: dpkg, apt, DAK, glibc, gcc. I don't think breaking them
at this time is wise.
| > | [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.
You're jumping through a lot of hoops to get to somewhere which is a bit
like multiarch, but not quite. And you'll end up with something less
capable, more ugly and a lot more work to support properly when
upgrading to multiarch. Doing the full dance is less work.
| 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.).
Huh? Where have you gotten the idea that lib and lib64 will be
symlinks? Have you actually _read_ the proposal?
| > 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.
The minimum number of times you'll break something is less with
multiarch than with biarch + multiarch. The amount of potential
breakage when going from uniarch to multiarch is less than going from
uniarch to biarch to multiarch or uniarch and biarch to multiarch.
Biarch is an unneeded step which complicates things.
| > | > 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?
I assume that means "no".
The right way is one which works properly on both uniarch and biarch
systems, always installing into the correct directories, handling file
overlaps properly and so on.
| > | 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.
You're claiming, for some reason, that amd64 needs to prepare for
multiarch migration in some other way than our 11 other architectures
because you think that the amd64 porters should support solving problems
for sarge a way none of the porters are willing to solve for sarge.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Reply to: