Re: Breaking /emul/ia32-linux for squeeze
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
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
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?
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.
>>> 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:
gcc -uclibc -c foo.c
[pid 10750] read(6, "#include <foo.h>\n"..., 17) = 17
[pid 10750] open("/usr/local/include/foo.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 10750] open("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include/foo.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 10750] open("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include-fixed/foo.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 10750] open("/usr/include/foo.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 10751] stat("/usr/local/include/x86_64-linux-gnu", 0x7fff9427a1c0) = -1 ENOENT (No such file or directory)
[pid 10751] stat("/usr/local/include", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
[pid 10751] stat("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 10751] stat("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include-fixed", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 10751] stat("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../x86_64-linux-gnu/include", 0x7fff9427a1c0) = -1 ENOENT (No such file or directory)
[pid 10751] stat("/usr/include/x86_64-linux-gnu", 0x7fff9427a1c0) = -1 ENOENT (No such file or directory)
[pid 10751] stat("/usr/include", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
[pid 10751] read(6, "#include <foo.h>\n"..., 17) = 17
[pid 10751] stat("/usr/local/include/foo.h.gch", 0x7fff94279f20) = -1 ENOENT (No such file or directory)
[pid 10751] open("/usr/local/include/foo.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 10751] stat("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include/foo.h.gch", 0x7fff94279f20) = -1 ENOENT (No such file or directory)
[pid 10751] open("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include/foo.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 10751] stat("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include-fixed/foo.h.gch", 0x7fff94279f20) = -1 ENOENT (No such file or directory)
[pid 10751] open("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/include-fixed/foo.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 10751] stat("/usr/include/foo.h.gch", 0x7fff94279f20) = -1 ENOENT (No such file or directory)
[pid 10751] open("/usr/include/foo.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
Where does it look for our $triplet dir?
/usr/x86_64-linux-uclibc/include
or in gcc terms:
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../x86_64-linux-uclibc/include
Same for -muclibc.
The directory it searches depends on the triplet gcc compiles for and -uclibc changes that.
Also notice what happens with -m32:
[pid 10924] stat("/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../x86_64-linux-gnu/include", 0x7fff93b83e10) = -1 ENOENT (No such file or directory)
[pid 10924] stat("/usr/include/i486-linux-gnu", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 10924] stat("/usr/include", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../x86_64-linux-gnu/include (being /usr/x86_64-linux-gnu/include) does not belong there.
So there is still some work to do on the includes I think.
The problem I found trying to implement the multiarch library paths in
gcc was that the decision has to be made at runtime and not only
-m64/-m32 influences it. I didn't find a way to check the target
triplet gcc is building for at the palce where it assembles the search
path in a way that -glibc/-uclibc would change it to fit the real
traget.
MfG
Goswin
Reply to: