Re: amd64 and sarge
Kurt Roeckx <Q@ping.be> writes:
> On Thu, Jul 29, 2004 at 09:47:31PM +0200, Goswin von Brederlow wrote:
>> Raul Miller <moth@debian.org> writes:
>>
>> > On Thu, Jul 29, 2004 at 09:53:56AM -0500, Pete Harlan wrote:
>> >> Multiarch, bi-arch, some people want them, that's great, but they're
>> >> simply offtopic with respect to the amd64 port.
>> >
>> > That said, the amd64 port can accomodate both without much problem.
>> >
>> > Bi-arch being less painful than multiarch, in my
>> > opinion -- it needs to touch far fewer packages:
>> > http://lists.debian.org/debian-amd64/2004/07/msg00244.html
>>
>> Biarch needs all packages to change. I repeat: _all_.
>> Multiarch only libs and debs with plugins.
>>
>> If you read/hear/say anything else its just not true.
>
> Did you actually properly read his proposal? It actually makes
> sense.
He misuses biarch where he means the Raul-Miller proposal. I got that.
But read it again:
|[1] modify dpkg, so that it can handle packages providing support for
|multiple architectures
Modifying dpkg that way for sarge is not possible.
| [a] packages have to list supported architectures in their control
| file (what it exports, not what it imports)
So make needs to export all archs, same for mozilla and axiom. Any
binary package needs to change?
| [b] unless package specifies otherwise, all its dependencies have
| to be satisfied by another package of its own architecture.
Or
Any depends on binary package must be specialised to work with any
other architecture. Any "Depends: sed" needs to be "Depends: sed:any"
or something.
Those two options already come down to changing every source package.
|[2] build packages to take advantage of this:
|
| [*] make important shared libs biarch
Change all core packages to biarch.
| [*] list amd64 packages which don't export shared library
| interfaces as supporting all architectures.
Change all non core packages.
| [*] introduce dependencies between important packages, reflecting
| the needs of an install onto i386.
??? Whatever that third point means.
Again that means changing all packages.
> What he's saying is what we currently use as bi-arch is not the
> way to go. We should not install all libs twice, once as i386
> and once as amd64. You only install the amd64 once.
Multiarch allows for a pure 32bit, pure64 or a mixed system. Whatever
the user wants. Same for the original biarch proposal.
His system means users are forced to have both i386 and amd64 libs
installed. Granted, they are in one package, but it is still the same
number of files installed.
> It also says that we don't need to move around all amd64 libs to
> the /lib64 dir. Only those for those that we make bi-arch we
> should put the i386 lib in /lib and the amd64 one in /lib64. All
> other amd64 libs can be in /lib until we feel the need to make it
> bi-arch.
That will give lots and lots of stupid warnings when compiling
packages. I tried that when bootstraping my multiarch chroot and its
not a nice sight. Certainly not suitable for a stable release. His
suggested workaround is ugly at best.
It also prevents i386 lib packages from getting installed without
problems. So no multiarch/biarch dpkg support or everything
breaks. You couldn't install any more i386 debs than with the
ia32-libs. Actualy way less since X libs aren't core packages.
> What it comes down too is that for all libs in the ia32-libs
> package we make an amd64 deb that has both the i386 and amd64
> libs in it. This first requires that we have a bi-arch gcc.
Ok, thats a different set of libs than the core packages.
> Then we can compile all those libs once using -m32 and once using
> -m64.
Actualy once with linux32 and once with linux64.
> I think this is a much better solution that the ia32-libs too,
> since that's just an ugly hack that uses i386 .debs, and you'd
> have to wait for fixes in those libs until someone makes a new
> ia32-libs package.
The ia32-libs is currently hacked. On the other hand it saves
rebuilding every deb twice. The current debian archive and
autobuilders are not equiped to build the ia32-libs package from
source. You would need to make a second source package which means
evenmore delays and work to get bugs fixed.
The ia32-libs package as it is now on the other hand can be rebuild
automatically with a small cron job. The i386 buildd could run it and
use the normal buildd way to get a signature.
> I think this is a solution that isn't too much work and can
> perfectly work. It should make migration from i386 rather easy,
> and even gets rid of the lib64 symlinks.
>
>
> Kurt
But what do you gain?
- You gain a multilib gcc.
What does it need?
- You have to change all amd64 packages.
- You have to change all libs from the ia32-libs package drastically.
What isn't solved?
- You still can't transparently install i386 debs.
- You can't run any more software than you already can.
So the only advantage is the multilib gcc support. All that needs
under the normal pure64 is an ia32-libs-dev package with the *.so
links and static libs and a small patch to gcc.
Skip all the dpkg changes and control file changes. Just add the few
missing files to ia32-libs or to a ia32-libs-dev package. That
acomplishes the same with much less work.
Another point:
|And, as long as a package's build depends are satisfied, there's no
|little danger of configure getting confused, because the dependencies
|will be satisfied. [There might be some exceptions, but they should be
|rare enough to be fixed on a case-by-case basis.]
He is right, there is 'no little danger'. The danger is huge. Just
think about *.la files or *.pc files. All those files that mention
core packages will be wrong for one arch or the other.
And there are a lot of exceptions looking in the wrong dir for libs on
amd64. That is why we even added a /usr/X11R6/lib64 link,
remember. All those X packages will break again if the link is
removed.
In conclusion I have to say that since amd64 isn't going into sid
anyway, is going to use multiarch (which is making great progres by
the way. Real soon porting base is done obsoleting 'biarch' anyway)
his proposal is just a big waste of time. It's 50% of multiarch in a
realy bad way.
MfG
Goswin
Reply to: