Re: amd64 and sarge
Raul Miller <moth@debian.org> writes:
> 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.
>
> Raul Miller <moth@debian.org> writes:
>> > 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?
>
> On Fri, Jul 30, 2004 at 01:25:38PM +0200, Goswin von Brederlow wrote:
>> No, its just a way to give the different proposals different names so
>> as to not confuse people.
>
> I don't think this is justified. The concept of "biarch" extends far
> beyond Debian. There's several different ways of dealing with Debian's
> requirements, but they're all proposals that fit the more general concept
> of "biarch".
Tough luck. There is the biarch proposal, the multiarch proposal and
yours. Pick a name that makes it clear what it is.
>> > Might work for sarge updates.
>>
>> That would be against the stable RMs policy even if you get the
>> support from the dpkg team.
>
> That policy might change.
Feel free to try and waste the RMs time.
> Alternatively, biarch might be made available in a different form.
>
>> >> 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.
>
> If my "it" you mean package changes -- no, that's not the case.
You still fail to convince me. In my eyes you lack the experience to
judge it.
> Packages already have architectures. Currently, that information isn't
> recorded on a per-package basis (there has been no need), but it's
> possible for an updated dpkg to begin doing so.
Well, guess again. dpkg does record the arch of every package it
installed. We patched that into dpkg long ago so the multiarch
transition after sarge can go smoothly.
>> > 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.
>
> Yes, it defaults to its own arch unless it states otherwise.
>
> Only key dependencies need to be updated.
>
> And, note that the base packages would all support biarch by default.
> [Which means anything without any explicit dependencies is already
> supported.]
>
>> >> 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.
>
> I'm not sure what your point is here -- yes, a "Depends: sed" would be a
> policy violation. I don't know why you picked that example. That's why
> I expressed the above paragraph so conditionally.
No,
debian-policy:
| 8.2 Run-time support programs
|
| If your package has some run-time support programs which use the
| shared library you must not put them in the shared library
| package. If you do that then you won't be able to install several
| versions of the shared library without getting filename clashes.
|
| Instead, either create another package for the runtime binaries
| (this package might typically be named libraryname-runtime; note the
| absence of the soversion in the package name), or if the development
| package is small, include them in there.
Packages containing libraries and binaries would violate 8.2. No point
making special cases for it, just file bugs.
>> > 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.
>
> I disagree.
>
>> >> 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.
>
> Option [a] is called an option because it's optional. That means you
> don't have to do it for every package.
>
> If you hae some point, please be more specific.
>
>> >> |[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.
>
> Only base packages have to receive special treatment (because every
> package has an implicit dependency on all base packages).
>
> Nothing else really has to be biarch.
>
>> >> | [*] 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?
>
> It's important to make a distinction between what's needed for
> the system to work [just change the packages which other packages
> depend on which people care about] and the simple policy statement
> [change everything].
>
> For biarch to work, you don't need to change everything. For everything
> else, it's a cosmetic issue -- changes can wait for years (for example,
> until the next routine update of that package).
For it to gain anything above the pure64 a lot needs to be
changed. And all the changes are wasted becase multiarch obsoletes
them.
>> >> 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.
>
> No, only the shared libraries need to be duplicated. You don't duplicate
> docs, executables, etc. etc.
Call it ~250 MB then. Still bloat 99% of all users don't want or need.
>> > "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.
>
> If I was convinced you understood the proposal, I'd take this
> more seriously.
>
>> > 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.
>
> Is this a claim that the current ia32 mechanism won't work here?
>
>> > 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).
>
> This statement of yours indicates to me that you don't understand the
> proposal.
No, you don't understand the problems involved since you never tried
any of you ideas.
Neither of our opinions will change unless you actually try your
proposal.
>> >> - 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?
>
> I do change the rules files for biarch packages, but there's little need
> for that for non-base packages.
If you only change base and not also the few extra (to the user)
essential libs from ia32-libs you loose a lot. Don't even go there.
>> >> 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.
>
> The i386 library debs have to not conflict with needed amd64 lib debs,
> or they won't get installed. I'm imagining that ia32 debs can be made
> to satisfy these dependencies.
How do you detect conflicts or doesn't conflict. There is nothing in
your proposal about that. That looks like wishfull thinking.
>> >> - 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?
>
> %s/ core / base/g
Base would reduce the number of packages you can run. So your proposal
would be less than pure64.
>> >> 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.
>
> That's a general failing of proposals. That's why it's worth talking
> about them.
That is the difference between the biarch and multiarch proposal and
your idea. The former two have been implemented, improved, tested,
prodded and the result of all that has been formulated into the
proposals.
You just propose and ignore all the experience from testing the
previous proposals.
> That said, could you be more specific about why you believe la and pc
> files are going to be a problem? [Er.. maybe wait on that till after you've
> understood how my proposal doesn't have to modify most packages.]
No, go learn. If you don't know what they are or contain you will have
serious problems with your proposal anyway.
>> > 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.
>
> So don't add -dev components.
>
> I'm not intending that my biarch proposal support building i386 packages.
>
> Building packages for multiple architectures is the thing that multiarch
> supports that biarch doesn't.
Then how do you want to build your debs? They are supposed to conatin
i386 and amd64. Your proposal seems to desperatly need the ability to
build both flavours and then merge them into one deb.
>> > 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.
>
> Sounds like it would be worth modifying libtool to do this systematically.
Doesn't work. libtool scripts are contained in the source
packages. After changing libtool you need to change every source
package to update the scripts.
>> The .pc files are used by gnome and gtk. ls /usr/lib/pkgconfig/
>
> Sounds like it would be worth modifying gnome's pkgconf suport to address
> this systematically. [Whatever it is that generates the .pc files.]
How? Both i386 and amd64 *pc files would end up in /usr/lib/pkgconfig/
for most things. Your proposal doesn't keep libraries seperate. You
need another hack to seperate 32bit and 64bit stuff just like your
proposed gcc hack.
>> >> 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.
>
> Could you be more specific?
Go and build packages and watch them fail.
> I'm still not convinced that you've understood the proposal.
>
>> >> 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.
>
> Not even support for upgrades from i386 to amd64?
No. Thats an esential part of multiarch. Multiarch allows the upgrade
from i386 to i386+amd64, from pure64 to i386+amd64, from ppc to
ppc+ppc64, from mips to mips+mipsN32+mips64, from mipsel to
mipsel+mipselN32+mipsel64, from sparc to sparc+sparc64, from s390 to
s390+s390x.
It even allows for ppc to ppc+ppc64+i386 and alpha to alpha+i386 (with
qemu) and kfreebsd-i386 to kfreebsd-i386+linux-i386.
Multiarch allows much more than your limited proposal.
>> 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.
>
> Ok, this wasn't in the proposals that I read.
>
>> multiarch strictly only requires the base packages to be ported but
>> gains useability with every package being ported on top of that.
>
> I don't think you're using the word "ported" in its usual sense, here.
>
> Could you explain this more fully?
Ported as in changed to follow the multiarch proposal and the porting
howto.
>> > 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.
>
> "...quickly enough..."
>
> --
> Raul
As soon as sarge is out of the way. Your proposal can't make it any
sooner either.
MfG
Goswin
Reply to: