Re: amd64 and sarge
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 <email@example.com> 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
> > 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.
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.
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.
> > 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
> >> 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.
> > 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
> >> 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.
> >> | 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
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
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).
> >> 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.
> > "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
> > 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
> >> - 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.
> >> 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.
> >> - 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
> >> 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
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.]
> > 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.
> > 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.
> 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.]
> >> 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?
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?
> 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?
> > 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.