Re: Ideas about the lib / lib64 names, subarchs, porting guidelines [Re: irc brainstorming notes]
Bart Trojanowski <bart@jukie.net> writes:
> * Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [031209 14:22]:
> > Bart Trojanowski <bart@jukie.net> writes:
> >
> > > I am officially excited again :) Once we settle on something I will
> > > start coding up the dpkg changes.
> > >
> > > [editorial note: I've changed one thing from our irc discussion, and
> > > that is the notation of the 'Depends' field. It's similar to what Adam
> > > Heath had in mind, iirc.]
> > >
> > > 1) we will have a modified autoconf that will default to .../lib64 for
> > > the 64bit architectures. Autoconf maintainers will likely refuse such a
> > > patch, thus this will be a Debian specific patch. This will reduce the
> > > amount of work required to port packages to amd64.
> >
> > For other subarchs that should default to the libdir intended for an
> > optimised library: i.e. compiling for i686 would end up in lib/i686.
> >
> > That way installing libfoo (i386) and libfoo (i686) won't conflict
> > even without special handling.
>
> 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.
> > > 6) When installing or upgrading a -v|--verbose (or -a|--arch) option
> > > will cause apt to print /${arch} after each package in the summary list,
> > > that is about to be installed or removed. This will allow users to
> > > catch any anomalies. Since it does not alter the default display it
> > > will not break any scripts that depend on the output of the original
> > > install and upgrade options.
> >
> > -u should display the packages grouped by subarchs or something.
> > Adding the subarch after each deb is way to much info, not mentioning
> > it too litle.
>
> 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.
> > 7) All packages that are ment to be installable for multiple subarchs
> > have to be split into foo and foo-common and all foo package may only
> > contain disjunct files. That means libfoo, libfoo-dev becomes libfoo,
> > libfoo-common, libfoo-dev, libfoo-common-dev.
> >
> > libfoo-dev would be the .a files, libfoo-common-dev the header
> > usually.
> >
> > /usr/lib/libssl.so -> libssl {i386}
> > /usr/lib/i686/libssl.so -> libssl {i686}
> > /usr/lib64/libssl.so -> libssl {amd64}
> >
> > "apt-get install libssl {i386} libssl {i686} libssl {amd64}" would
> > work.
>
> 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.
MfG
Goswin
Reply to: