Bug#246547: [RFC] Re: Bug#246547: glibc: amd64 support is missing
* GOTO Masanori ([EMAIL PROTECTED]) wrote: > BTW, this proposal does not dig the "/bin" path issue. If we have > both 32bit (i386) database binary (ex: mysql) and 64bit (amd64) > binary, where do we put those binaries? (I think one way to solve > this problem is: to make /arch-os/bin for /bin, /usr/arch-os/bin for > /usr/bin.) I believe the intent is that this won't be supported. mysql i386 will conflict with mysql amd64. To do otherwise would introduce quite a few other issues. As for 64bit libraries in /lib64, it's just short-sighted and kind of silly. Additionally, the requirement I've seen has been the location of the loader, which we can conform with using symlinks. The libraries themselves I don't believe are constrained to a specific location (as it should be). Stephen signature.asc Description: Digital signature
Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
* Aurelien Jarno ([EMAIL PROTECTED]) wrote: > The FHS is actually not very clear, as it says 64-bit libraries should > be in (/usr)/lib64, whereas system libraries should be in (/usr)/lib. > This is a contradiction for a pure 64-bit system. The FHS is very clear about the path to the 64bit linker, and that goes through /lib64, getting rid of that isn't an option. > - I am not sure that creating the link in postinst will work. Creating > it in preinst looks safer to me. I'd be a little nervous about creating it in postinst too, honestly. > - If you can install files in (/usr)/lib64, the files will end up in > (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other > tools won't work correctly. Yeah, I'm not sure it really makes sense to need to install into both... It would have been much more useful for you to include the *reasoning* behind Goswin's request rather than just your reasons for not wanting to do what he's asking. > - If you have two packages providing the same files in (/usr)/lib and > (/usr)/lib64, then the files will be overwritten without warning. This > is IMHO not acceptable. My guess is that his intent was actually to allow *seperate* packages to install into either /lib or /lib64 on a package-by-package basis. This might resolve some bugs in packages which, when they detect they're being compiled for amd64, default to installing into /lib64 instead of /lib. Personally I think that's something that just needs to be dealt with and those packages should be fixed but that's my guess as to where the question came from. It's also possible a given package wants to install some things in /lib64 (say, actual libraries) and other things in /lib (say, helper programs, ala blah-config). > Could you please give me your opinion on that, so that I can take a > decision? The link itself certainly can't go away. I'd be more inclined to say "progams on a pure 64bit platform shouldn't install into /lib64" than to have some things installing into /lib and others into /lib64. Part of this comes from the concern that this will bring out other bugs in packages where having this distinction might cause overlaps as mentioned above. Thanks, Stephen signature.asc Description: Digital signature
Bug#189192: Fixed in glibc CVS
This bug appears to have been fixed in glibc CVS. Specifically version 1.47 of sysdeps/generic/glob.c viewable here: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/glob.c?cvsroot=glibc There were changes to the globtest.sh to test for the bug in the future too. Stephen pgp0.pgp Description: PGP signature
Bug#189192: glob() busted when symlinks to directories used in path
Package: glibc Version: 2.3.1-16 Severity: normal glob() is busted in glibc because it does not correctly handle the situation where a symlink is part of a path. For example: There exists a symlink: /data/a -> /data1/a /data1/a is a directory which contains: abc def xyz A glob() call using the pattern: /data/*/* will fail. This is because around line 1373 of glob.c there exists the following code: --- #ifdef HAVE_D_TYPE /* If we shall match only directories use the information provided by the dirent call if possible. */ if ((flags & GLOB_ONLYDIR) && d->d_type != DT_UNKNOWN && d->d_type != DT_DIR) continue; #endif --- When a path element is a symlink the d_type for it is DT_LINK. DT_LINK should probably be added to the statement above as another valid type. Of course, another check will need to be made if you want to be sure the symlink points to a directory. This check should probably work on any type of file and be outside the #ifdef above so that GLOB_ONLYDIR will work when HAVE_D_TYPE isn't defined (as I read it this isn't the case currently). Stephen pgp6J6B9iFWva.pgp Description: PGP signature
Bug#189192: Fixed in glibc CVS
This bug appears to have been fixed in glibc CVS. Specifically version 1.47 of sysdeps/generic/glob.c viewable here: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/glob.c?cvsroot=glibc There were changes to the globtest.sh to test for the bug in the future too. Stephen pgpsA6J6i9d3V.pgp Description: PGP signature
Bug#246547: [RFC] Re: Bug#246547: glibc: amd64 support is missing
* GOTO Masanori ([EMAIL PROTECTED]) wrote: > BTW, this proposal does not dig the "/bin" path issue. If we have > both 32bit (i386) database binary (ex: mysql) and 64bit (amd64) > binary, where do we put those binaries? (I think one way to solve > this problem is: to make /arch-os/bin for /bin, /usr/arch-os/bin for > /usr/bin.) I believe the intent is that this won't be supported. mysql i386 will conflict with mysql amd64. To do otherwise would introduce quite a few other issues. As for 64bit libraries in /lib64, it's just short-sighted and kind of silly. Additionally, the requirement I've seen has been the location of the loader, which we can conform with using symlinks. The libraries themselves I don't believe are constrained to a specific location (as it should be). Stephen signature.asc Description: Digital signature
