Ideas about the lib / lib64 names, subarchs, porting guidelines [Re: irc brainstorming notes]
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.
> 2) we will drop lib64 package prefix. 32bit and 64bit packages will be
> prefixed with lib as before. This will simplify dependencies in control
> files since all packages will only have to state their dependencies on
> libfoo, and not lib64foo.
Same for lib-dev. lib-dev packages count the same as libraries,
i.e. the ABI must be compatible and not just the subarch.
Instead of adding varibales or .64 packages to the control file for
each library depends a {abi} is added. For debs the shlibs thing would
do most of the work. Changes to the rules file would also disapear
unless they don't use autoconf to compile and install the libraries.
The number of packages that don't is small though.
> Here is an example of a source control block:
>
> Source: bar
> Depends: libfoo {abi}
Build-Depends: libgurks-dev {abi} (>> 1.2.3) [!hurd-amd64]
(to make it more intresting)
> Source: libfoo
> Depends: libbar {abi}, goo
>
> ... and the binary packages:
>
> Package: bar
> Architecture: i386
> Depends: libfoo {abi} (= 0.0.0)
Depends: libfoo {abi} (>= 0.0.0) libgurks (>= 1.2.3)
(more likely and with the build-depends shlibs magic added)
> Package: libfoo
> Architecture: i386
> Depends: libbar {abi} (= 0.0.0), goo (= 0.0.0)
Depends: libfoo-common (= 1.2.3), libbar {abi} (= 0.0.0), goo (= 0.0.0)
I gues nearly every lib has some common files.
> Package: bar
> Architecture: amd64
> Depends: libfoo {abi} (= 0.0.0)
>
> Package: libfoo
> Architecture: amd64
> Depends: libbar {abi} (= 0.0.0), goo (= 0.0.0)
>
> Note the {abi} which is equivalent to your Depends-ABI. But would be a
> bit cleaner since it would not require Pre-Depends-ABI,
> Build-Depends-ABI, etc. It mostly simplifies the parsing code, makes
> things more generic, and is closer to what Adam had talked about a few
> months ago.
If {} is free and not intended for something else in dpkg 2 already by
all means use it.
> 3) we will add an extension to apt to be able to install a specific
> architecture's binary:
>
> apt-get install foo/i386
> apt-get install foo/amd64
apt-get install foo/i386=1.2.3 for even stricter debs?
foo/arch=version or foo=version/arch?
foo=1.2.3/i386 looks better I think but both should work so noone is
surprised.
> If a package is not available it will try to install a compatible ABI's
> package. Say you want to install foo/i686, but it's not available. apt
> will attempt to install i586, i486, or i386 if possible -- since they
> are equivalent. A warning will be printed.
But only when manually setting the arch. When selecting i386 instead
of amd64 for "apt-get install foo" I don't want a warning.
> 4) dpkg will parse the subarchtable that will let it figure out what
> architectures are compatible. This is done, but is currently a fork of
> a dpkg-subarchitecture perl script.... this was a shortcut that needs to
> be fixed.
>
> 5) apt will fetch all compatible architectures from the mirror. Ie it
> will get the packages list fro binary-{i386,i486,i586,i686,amd64}. An
> /etc/apt/* setting will be available to specify what architectures
> should be included/excluded from the fetch. Default will likely be i386
> and amd64 for the amd64 distribution.
Default will be all compatible subarchs but only the primary should
give an error. It would probably be good to cache what archs where
found the last time and warn/question/fail when the set of archs
changes. Default would be question.
"New compatible subarch i686 found. Do you want to use this subarch?"
> 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.
When upgrading, is foo 1.2.3 {amd64} a newer version then foo 1.2.3
{i386}? I would suggest that the first package found when following
the compatible subarch links (the package with the shortest path from
arch to subarch if we ever make a tree out of them) is considered the
higher version if they are equal otherwise.
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.
8) Optimised libraries for libraries in /lib need special dependencies
if they want to go to /usr/lib.
Say I install a libc6 {i386} and libc6 {i686}. But libc6 is big so one
doesn't usually want both in /lib. /usr/lib/i686/libc6.so is perfectly
fine for the optimised libc as long as the unoptimised /lib/libc6.so is
present. But both libc6 {i386} and libc6 {i686} use "ABI: i486". Dpkg
will think any one of them will do.
If libc6 {i686} wants to install to /usr/lib/i686 then a "Depends:
libc6 {i386}" must be added. libc6 could use "Depends: libc6 {i386}
[!amd64 !i386]" in the control file. To generalize this what about
"Depends: libc6 {baseabi}". But I think the very few cases in /lib
that utilize optimised arch can probaly do with "Depends: libc6 {i386}
[!amd64 !i386]". Locally I only have libcrypt in /lib thats optimised
for i686/cmov.
[ Libraries and programms with optimised subarchs would also need to
somehow tell the autobuilders that the package should be compiled for
multiple subarchs. It is probably enough if the autobuilders keep a
list of such packages. If someone cares there is no reason not to
compile a lib for a more optimised subarch, itsjust that debian
doesn't by default. I see no reason to include information of debians
preference what to optimize in the control file. ]
9) Depends: foo {i386, !i486, i686} syntax
Binaries are equivalent for all subarchs. It does not matter what
"make" I install. So "make" is not supposed to be installed for
multiple subarchs at the same time. Exception to this (currently) is
our toolchain. We want to keep our toolchain strictly 32 bit until the
problems there are ruled out.
For cases where binaries of a compatible subarch won't do the Depends
line should contain the respective architectures, e.g.:
Package: build-essential
Depends: libc6-dev | libc-dev, gcc {!amd64} (>= 3:3.3), g++ {i386, !i486, i686} (>= 3:3.3), make, dpkg-dev { (>= 1.4.1.19)
We accept any gcc not 64 bit but g++ must be i386, i586 or i686 [i586
is a compatible subarch]. Or should that be just i386 or i686?
My logic would say that for each arch in {} the subarchs are tried
recursively unless that subarch is excluded (then the recursion stops,
i.e. {i386, !i486, i686} would try i386, all and i686, i585 and i484
(which gets droped because its excluded and stops the recursion).
{!amd64} on the other hand would mean we try amd64, which gets droped
and stops the recursion. So no subarch is found. Thats not what we
want. If the target arch itself is excluded I take that to mean that
subarchs would still be ok. If you think thats too obscure then
{!amd64, i686} would be the correct entry.
10) the hold status of dpkg could be expanded to keep a package on the
same subarch when upgrading:
echo package hold-subarch | dpkg --set-selections
or
echo package hold-i586 | dpkg --set-selections
Reply to: