Re: -= PROPOSAL =- Release sarge with amd64

[Gerd Knorr <kraxel@debian.org>]

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.

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
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.

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.

  Gerd

-- 
return -ENOSIG;