Re: amd64 and sarge
> > Did you actually properly read his proposal?
On Fri, Jul 30, 2004 at 12:53:06AM +0200, Goswin von Brederlow wrote:
> He misuses biarch where he means the Raul-Miller proposal. I got that.
This seems a rather silly objection. I'm guessing that you want to
pretend that there's only one way of achieving biarch support in debian.
But how does that benefit you?
> 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.
Might work for sarge updates.
> | [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?
I don't understand the question.
You should not have mozilla get the new control file line. Tha would
defeat the point of the exercise.
Adding it to make would allow the support of i386 packages which depend
on make, so would be a good idea (but it's not critical -- merely an
improvement).
Adding it to axiom seems silly unless I'm missing something crucial.
The only package I see which depends on axiom is axiom-databases --
if you absolutely must have the i386 version of axiom, install the i386
version of axiom-databases. But I don't see what advantage this gains.
> | [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.
If sed wasn't a base package, and sed hasn't been changed yet to note
that it supports any architecture, this hack would work. But the real
purpose, here, is for packages which depend on another package which
provides both shared libraries and executables -- it indicates that the
shared libraries aren't needed.
That said, sed is a base package, and I've not seen any "Depends: sed".
> Those two options already come down to changing every source package.
This is false. I don't see any real basis for this statement. In your
above comments, you've identified one package where modifying the control
file would have some benefit. You falsely claimed that mozilla should be
modified, and that there was some package that needed "Depends: sed:any".
I'm extremely dubious about your claim that axiom needs to change.
> |[2] build packages to take advantage of this:
> |
> | [*] make important shared libs biarch
>
> Change all core packages to biarch.
Why?
This seems to be based on the false idea that every package has to change.
> | [*] list amd64 packages which don't export shared library
> | interfaces as supporting all architectures.
>
> Change all non core packages.
No.
> | [*] introduce dependencies between important packages, reflecting
> | the needs of an install onto i386.
>
> ??? Whatever that third point means.
>
> Again that means changing all packages.
It means installing dependencies in base packages on other base packages
where it's possible that dpkg would screw things up when installing
biarch amd64 on an i386 system.
And, more generally, if there were some requirement that all packages be
changed it would be better to fix dpkg/apt so dpkg can be more systematic.
> > 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.
This seems like a trivial point.
> > 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.
Do you have any more specific objection than "it's ugly"?
"It's ugly" might mean that there is some real technical problem,
or it might not.
> 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.
I'm intending for the ia32-libs to remain, for the most part.
Also, "core packages" is a somewhat informal term. I've seen amd64 docs
which don't list x lib packages as "core packages", but I've seen other
documents which mean "everything included in standard".
I wrote that proposal with the idea that there wasn't anything wrong with
the ia32 libs which the amd64 port introduces. If you want to claim that
they are a problem, that's an issue I'm ignorant of. I'd appreciate it
if you could point me at discussion of this problem.
[Or is it just your comments and Kurt's comments, in this thread, which
indicate the nature and scope of this ia32 issue?]
> But what do you gain?
>
> - You gain a multilib gcc.
>
> What does it need?
A multilib glibc.
> - You have to change all amd64 packages.
False.
> - You have to change all libs from the ia32-libs package drastically.
False. [At least, not if we're still discussing my proposal.]
> What isn't solved?
>
> - You still can't transparently install i386 debs.
You can, in some cases, where there's no amd64 alternative.
Where this is important (mozilla+flash, for example), it's
straightforward to make possible.
> - You can't run any more software than you already can.
While this is false, it's true that running more software wasn't the
only point of the proposal. [Support upgrade to amd64 from i386 was
another point.]
> 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.
False.
I've already gone over this point enough times in this message.
> 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'.
That was a typo. I meant to write "there's no danger" or "there's 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.
I'm not familiar with this danger.
On the debian system I'm currently working with, about 3% have libtool
.la files, and I don't see any .pc files. It seems to me that if this
is such a huge issue that the use of ia32 files would have the same problem.
Alternatively, it might be possible to fix libtool (if I had a decent
idea of what problems you're talking about, I might be able to say
something more concrete).
> 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.
Are you claiming that the ia32 approach doesn't work here?
> 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.
I think some of the ideas from my proposal would benefit multiarch
(they're very simple -- stuff like having a default architecture to be
used at package selection time in the absence of an explicit architecture,
but also some of the thought about how to make changes systematically
without having to touch every package -- for example, allowing packages
to claim that they only export binary-independent interfaces).
If multiarch incorporates these sorts of things, and also addresses the
"upgrade from one architecture to another" issues quickly enough, I'll
drop my proposal.
That said, my proposal is far less invasive than you claim, and I think
it's possible to have it ready to be incorporated in a sarge-update
mini-release.
--
Raul
Reply to: