* Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [031209 16:55]: > > I am not sure if I agree with you there. It seems like you are taking > > the flexibility a bit too far. > > > > I can see why we need to have /lib and /lib64, but I don't see the need > > of having i386 and i686 libraries installed concurrently. If your > > application requires a 32bit version of a library it should not care if > > it's i386 or i686. Things will still run if you have one or the other > > -- unlike the case of i386 vs amd64. > > > > I could be missing something however. > > Its just the way it currently works. openssl puts a i386 lib into > /usr/lib and an optimised lib into /lib/i686/cmov. The ld will pick > the faster one if the cpu supports i686/cmov features. Oh, ok. Then I will not worry about it since it sounds like there is no extra support to be added. It will be likely that instead of installing libssl-i686-version_i386 ppl will start o building libssl-version_i686... that is once there is support for it. Then this whole /lib/i686 could go away, no? > > I was hoping to not have ot change the output too much. Ie, leave -u in > > the format that it's in now, and add a new format w/ the arch info. You > > are probably right, grouping by arch would be better. > > -uu or -u -u for more "u"? -U? something. sure -u -u works. > > Again, I am not sure if that is not too much. I belive that libssl/i386 > > and libssl/i686 are mutually exclusive since they provide the same ABI. > > I don't realy care about i686 optimised libs going to lib/i686. Its > just the way its currently done so libfoo.deb can contain both i386 > and i686 libs. > > For all I care the bloated i386 deb can remain. I someone cares he > could split it up and having libfoo and libfoo-common (instead of > lib64foo depending on libfoo for common files) would make that easy. Right. I missed that. Carry on... nothing to see here. B. -- WebSig: http://www.jukie.net/~bart/sig/
Attachment:
pgplhV0SR8HT4.pgp
Description: PGP signature