* 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.
> > 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.
From what I read on debian-dpkg, dpkg2 will use {} for this kind of
stuff, ie keywords.
> > 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.
I cannot see why both could not work. = would be a prefix for version
and / would be a prefix for arch.
> > 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.
Sure, that makes sense. If unspecified it should take the "best" (top
in the subarch tree) that can be executed on the host's architecture.
> > 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.
> 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.
I agree with that.
> 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 agree with most of the stuff I've read except for this one. :)
B.
--
WebSig: http://www.jukie.net/~bart/sig/
Attachment:
pgpvU8B55NvoR.pgp
Description: PGP signature