Re: amd64 and sarge
Raul Miller <moth@debian.org> writes:
>> > 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?
No, its just a way to give the different proposals different names so
as to not confuse people.
>> 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.
That would be against the stable RMs policy even if you get the
support from the dpkg team.
>> | [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).
You need it for every binary something depends on and said something
should be installable as amd64 or i386 package.
> 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.
You are not giving an option. 'packages have to list...'. It is
unclear what happens if there is no list. I assume without list it
defaults to its own arch only which makes it quite useless unless the
majority of packageshave a list.
>> | [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 would be a policy violation. No package may contain public
libraries and public binaries.
> That said, sed is a base package, and I've not seen any "Depends: sed".
Just an example. Pick any non essential binary with depends on
it. Unless a large number of binary packages have this you don't gain
anything.
>> 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.
You don't allow for not modifying in option [a]. And even if you add
that you loose usability wth every package not having the list.
>> |[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.
To make them biarch, what else.
>> | [*] list amd64 packages which don't export shared library
>> | interfaces as supporting all architectures.
>>
>> Change all non core packages.
>
> No.
How else do you get the amd64 packages flaged to not have shared
libraries?
>> | [*] 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 bloats a base install from ~150 to ~300 mb.
>> > 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.
No. Technically it is possible. Its just a stupid way to work around
problems that multiarch avoids and a pain to maintain with a changing
number of libs being ported.
>> 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".
Yes, very informal. Without 32bit X libs you can't use any graphical
program thats dynamically linked. I would think they are quite
essential to some users. I would think having X biarch is required for
any useable system.
> 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.
You propose a lot of work that gains nothing unless the majority of
packages or all packages are changed. Only then you gain anything
above what ia32-libs already does (apart from the multilib gcc).
And all the work is for nothing and better spend on multiarch
directly.
> [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 might have ment something less drastic but you didn't write it.
>> - You have to change all libs from the ia32-libs package drastically.
>
> False. [At least, not if we're still discussing my proposal.]
Yes, your proposal. You need to change the rules file to build i386
and amd64 and then merge the two. Or how do you suppose you get the
merged packages?
>> 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.
If you allow that i386 library debs will be installable and break the
system. Even worse, if you have apt pick i386 packages when no amd64
version is available an upgrade will wreck the system pretty quickly.
>> - 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.]
Since you only want to make the core libs biarch you can only run
things depending only on the core libs. That means everything you can
already run with ia32-libs. Where is that false?
>> 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.
That is the problem. You never tried any of what you propose.
> 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.
Since ia32-libs has of yet not -dev component the issue doesn't arise.
If that is added it would be an issue.
> 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).
The la file specify the lib_dir for example. For 32bit that needs to
be /lib or /usr/lib and for 64bit /lib64 or /usr/lib64 (for all biarch
libs). Of cause you can put the 64bit la files into /usr/lib64 but
then you need to change sources to look in both places.
The .pc files are used by gnome and gtk. ls /usr/lib/pkgconfig/
>> 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?
Yes, it doesn't work there. A lot of sources need to be patched to
work for biarch. The pure64 works around the problem by having lib64
and lib in one place.
>> 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).
I see nothing that is not already in multiarch.
Packages that only export binary-independent interfaces set
"Multi-Arch: no". Libraries set "Multi-Arch: yes". Unported (or not
multiarch supporting) packages have no line. That covers all cases.
apt-get/dpkg will follow its arch table prefering the earlier entries
(its default arch) over the later ones.
multiarch strictly only requires the base packages to be ported but
gains useability with every package being ported on top of that.
> 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 has all always been in multiarch.
> 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.
No. That is already vetoed by the stable RM. Its also far to invasive
since it needs changes to dpkg and other core packages.
Those changes are not security fixes and wouldn't be allowed into a
sarge update.
> --
> Raul
MfG
Goswin
Reply to: