Re: -= PROPOSAL =- Release sarge with amd64
Gerd Knorr <kraxel@debian.org> writes:
> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
>
>> No, the aim is just for lib and, where needed, include. The aim is
>> also to do as much as possible through moving files in the debs
>> without large source changes. It could be someone comes up with a
>> great way to write a dh_libs that will usually do all the multiarch
>> stuff. Things like that would make porting of a lot of packages trivial.
>
> That isn't going to work for lots of packages, you can't let dpkg or
> some debhelper script move around the files without the package
> knowing about it in many cases. That may work for shared libs, but
> will break badly for any other arch-dependant files which are
> currently somewhere below /usr/lib. The apps will not find the stuff.
> Plugins, data, whatever is there.
Yes, you are totaly right.
But think about what packages need to move their files. Only packages
that have to be coinstalled for two archs. That basically means only
library packages. And libraries don't tend to have arch-dependant
files in /usr/lib.
Exception will need extra work but there shouldn't be that many.
> You basically have to teach every single package that $libdir might be
> something else than $prefix/lib. And you really have to go the route
> from the very beginning and build the packages using something like
> "./configure --libdir=$prefix/$(DEB_BUILD_LIBDIR)", with
One plan is to patch autotools to default to the right libprefix. In
many packages the dh_install or dh_move files will then have to be
changed to use variable substitution for the path for libs, like
${libprefix}/*.so.
As I said, we know how to do this by hand, how to change the configure
to use --libdir, change the dh_install/dh_move file to a different
fixed path and so on. Working out where something like variable
substitution can be used or other tricks to simplify porting to
multiarch is still an ongoing process. There are still lots of ideas
to try out.
> DEB_BUILD_LIBDIR being "lib/$arch-$os" or "lib64" or whatever you
> like. The amount of work is the same, no matter how you call the
> directory in the end.
Yes. The difference between "lib/$arch-$os" and "lib64" is that the
former can keep the lib64 -> lib link and utilize all of pure64 while
the later needs to start from scratch.
Using a variable like DEB_BUILD_LIBDIR set by 'dpkg-architecture
-qDEB_BUILD_LIBDIR' for example is definetly a good idea.
> It is probably a good idea to add such a variable to dpkg _now_ (and
> set it to "lib" unconditionally for sarge). So packages can start
> using it, makeing the switch to multiarch a simple rebuild of the
> package with a multiarch-enabled dpkg. That will also simplify
> backporting multiarch-enabled sid packages to sarge.
Agreed. The multiarch group in the debian-amd64 team has to hurry on
that one so it gets included in sarge. There are a few things like it
that probably should go into sarge so people can start using them in
sid.
But its not essential. If its not ready its not the end of multiarch
in sarge+1. Afaik its not required to have sarge+1 sourcen be
buildable with sarge tools. Only the binaries must have a smooth
transition, the source can Build-Depend (or build-essential depends)
on newer versions.
> Gerd
MfG
Goswin
Reply to: