Re: Breaking /emul/ia32-linux for squeeze
On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote:
> Aurelien Jarno <aurelien@aurel32.net> writes:
>
> > Goswin von Brederlow a écrit :
> >> Aurelien Jarno <aurelien@aurel32.net> writes:
> >>
> >>> On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote:
> >>>> On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote:
> >>>>> ]] Clint Adams
> >>>>> | It may be time to change packages installing files to
> >>>>> | /emul/ia32-linux (which violates the FHS) to use
> >>>>> | /usr/lib32 instead.
> >>>>> Could we pretty please use the multiarch paths here if we start moving
> >>>>> stuff around? We're going to need to patch gcc/binutils if we're to
> >>>>> compile stuff against those paths anyway.
> >>>> What transitional issues is that going to cause us if and when multiarch
> >>>> becomes generally available, if biarch packages start using the path now?
> >>>>
> >>> Note that i386 libc on amd64 has used once the multiarch paths. This has
> >>> been reverted to the current path, because there was no clear plans
> >>> about a transition to multiarch. I think this still applies.
> >>
> >> You couldn't compile anything for 32bit anymore.
> >>
> >>> One of the goal of multiarch is to avoid having packages containing
> >>> binaries of a different architecture than the one of the package (e.g.
> >>> i386 binaries in an amd64 package), in order to make packages of
> >>> different architecture co-installable. If we start to break this goal,
> >>> we will have packages using the multiarch path, but not co-installable,
> >>> for example i386 libc bundled in an i386.deb and in an amd64.deb won't
> >>> be co-installable.
> >>
> >> Already broken for 2 stable releases.
> >
> > We are not using multiarch paths in Debian, so this has never happens.
> > When using standard /usr/lib paths, people are expecting that the paths
> > collide. When using multiarch they do not expect that, as it the goal of
> > multiarch.
>
> All biarch packages contain binary objects of a foreign architecture
> (that is kind of the point of them). Some do contain binaries. Some
> contain conffiles. One contains the dynamic loader. Prime example is
> libc6 vs. libc6-i386/amd64.
>
> Using the multiarch library path already and in biarch packages just
> changes the number from 5 to 25 or thereabout.
>
> Note that libc6 and libc6-i386/amd64 will neccessarily always conflict
> due to the dynamic linker and I believe every single biarch package
> depends on the libc. So they will never be coinstallable. The question
> is just how much Conflicts/Replaces are needed for the upgrade path.
>
> >>> IMHO, we should have a clear transitional plan to multiarch before we
> >>> start using multiarch path, in order to make sure we are not creating
> >>> problems that has to be solved later.
> >>
> >> libfoo (i386) Conflicts: lib32foo, Replaces: lib32foo
> >> libfoo (amd64) Conflicts: lib64foo, Replaces: lib64foo
> >>
> >> or
> >>
> >> libbla (i386) Conflicts: ia32-libs, Replaces: ia32-libs
> >> libbla (amd64) Conflicts: amd63-libs, Replaces: amd64-libs
> >>
> >> Adding that will let dpkg know how to handle the transition just fine.
> >
> > Meaning we need to have that for each package previously available as a
> > biarch package. Seems to be complicated for no real gain.
> >
> > Let me ask you a question: What would be the gain of using the multiarch
> > path for the biarch packages?
>
> Instead of violating the FHS we would follow a hopefully future FHS
> while still violating the existing FHS. So nothing really.
>
> I'm totaly fine with leaving the biarch packages where they are. I
> would like some push behind using multiarch paths for native packages
> though. Or rather I want them gone and replaced by ia32-apt-get.
>
> > For me pushing that is the wrong way to get multiarch support in Debian.
> > If we want it, we need to move the main librairies to the multiarch
> > path. And it is something I proposed for glibc once we have proper gcc
> > support, and a stabilised glibc 2.9. This choice still needs to be
> > validated by other persons though (like the RM team).
>
> Full ACK.
>
> > Last but not least, what is really need to have multiarch support in
> > Debian is a proper support in dpkg. They are some code already done by
> > Tollef, they are some ideas floating around, but they are still some
> > design decisions to be taken, and nobody has a real patch that can be
> > applied to dpkg. People are pushing hard to have multiarch support, but
> > no one seems to care about actually writing code.
>
> Pre sarge we had a dpkg that could install multiarch just fine but
> lacked some handholding when upgrading packages when they switched
> between arch all/any. Bitrot and redesigns in dpkg have made the patch
> kind of useless though and it needs to be rewritten.
>
> As for design decisions the only ones I know are missing are all
> cosmetic. They don't imapct the algorithm, just the look&feel:
>
> 1) How to specify an arch in sources.list?
>
> Suggestion:
> deb [arch=i386,amd64] http://ftp.debian.org sid main
>
> 2) How to specify a package including the architecture?
>
> Suggestions:
>
> Depends: foobar/i386
> Conflicts: foobar [i386]
> Replaces: i386-foobar
> Suggests: foobar=amd64
>
> apt-get install amd64/foobar
Those both questions concerns apt. I am not sure it is the way to go.
Having a working dpkg is the first way to go. Then we can start
thinking about apt.
> 3) Where should dpkg put maintainer scripts and package data?
>
> Suggestions:
>
> /var/lib/dpkg/info/i386/libc6.list
> /var/lib/dpkg/info/i386-libc6.list
> /var/lib/dpkg/info/libc6/i386.list
> /var/lib/dpkg/info/libc6-i386.list
> /var/lib/dpkg/info/i386/libc/libc6.list and .../info/i386/f/foobar.list
What about /var/lib/dpkg/info/libc6.i386.list, as we do for a lot of
stuff in debian (like debian/ directory of a package).
> Do we move existing files, in case of subdirs link the current arch to
> /var/lib/dpkg/info/ or do we look in both the old and new places?
I think we should not try to convert anything, as it is a way to break
stuff. Looking for both place should not be a big deal.
> Note that apt-cross and ia32-apt-get can be used already to install
> multiarch with a certain amount of hacks and failures. Converting
> packages to multiarch layout would remove the need for those hacks and
> remove the failures. So everything can be tested even without dpkg
> having the final support for it. The final solution could even be to
> just do the on-the-fly conversion of package metadata directly in apt
> and dpkg without touching anything else.
I do not trust on-the-fly conversion, this will only create problems. We
have to add a tag to debian/control saying "multiarch compliant
package".
> >>> OTOH, as soon as we have the toolchain fully supporting multiarch path
> >>> support (there is a missing part in gcc, that was thought to be fixed
> >>> binutils [1]), I am not opposed to switch the main glibc to the multiarch
> >>> path.
> >>>
> >>> [1] I offered to write it, but I haven't found time yet, so a patch is
> >>> welcome.
> >>
> >> Binutils upstream has vetoed adding multiarch paths saying it is gccs
> >> job. The BTS has a simple patch for gcc using the specs file to add
> >> the multiarch dirs without loosing the biarch dirs.
> >>
> >> Did you have anything more complex in mind to fix this?
> >
> > This patch looks a bit hackish and it has to be done for each
> > architecture. Mathias requested that something more automatic using
> > debian/multiarch.inc is done.
>
> I'm not sure if that is sufficient:
The *has to be written*, so the current version is clearly no
sufficient.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: