Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <moth@debian.org> writes:
>> | 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?
Yes, its just you. Multiarch will not be an issue for sid for a long
time to come. If you want it work on it but it just confuses in the
GR.
> 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?
Replacing one file with two files with the same name and path from two
different packages with the same name but different arch for example.
>> | [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.).
You can port all packages from pure64 or i386 to multiarch while still
only using uniarch. You can move the libs around to the new place one
by one by having both places in ld.so's search path.
What can't be done without problems is mixing 32bit and 64bit
libraries in the same dir. What also can't be done is use just lib64/
because of the extra work it entails porting all the library packages.
To get anything useable within a short timeframe the pure64 hack of
linking lib64 and lib into the same place and only having one ABI
there is the only possibility.
That said, you could start porting the base libs to be installed where
multiarch will put them now (or to where you say) starting with either
32bit or 64bit as base without including the actual multiarch dpkg/apt
support. But hey, you would still be implementing parts of multiarch.
>> 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?
In a way that has a minimum impact on the tools and sources. The les
that needs to be changed and the simpler the change the better.
Like asking dpkg where libs should end up and using that as a variable
instead of just replacing lib/ with foobar/ (as an example).
>> | 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
I think only one thing has to still happen now: You have to understand
that full biarch LSB compliance for amd64 requires most of the work of
porting something to biarch already, that going to LSB compliance
without going straight to multiarch is wasted work and that a clean
LSB compliance can only be achived once everything has been ported.
[as long as you want a 64bit system with the ability to also run 32bit
and not the other way around]
MfG
Goswin
Reply to: