[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ideas about the lib / lib64 names, subarchs, porting guidelines [Re: irc brainstorming notes]

* 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. :) 


				WebSig: http://www.jukie.net/~bart/sig/

Attachment: pgpNpTBvUlYTB.pgp
Description: PGP signature

Reply to: