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

Re: Bug#317082: Not just a dpkg bug

At Wed, 17 Aug 2005 22:05:42 +0200,
Andreas Jochens wrote:
> I guess you will generally have many more issues than this one when you 
> try to build 64-bit packages on a 32-bit buildd (e.g. compiling and 
> running 64-bit programs from configure scripts, running 'make check' or 
> 'make test' targets, using binaries which have been built by the package 
> itself etc.)
> In the end it will be much easier to require a 64-bit machine to be
> used to build 32/64-bit biarch packages instead of trying to circumvent 
> all these issues.

Yes, that's one solution.  However, instead, I would like to propose
supporting 32bit and 64bit binaries as separated architectures.

For example, think about ppc32 and ppc64.  My proposal is to have both
Debian/dists/sid/main/binary-powerpc and
Debian/dists/sid/main/binary-ppc64.  It's similar to the different
architecture between i386 and amd64 - but ppc32 and ppc64 are not
distinguished so much.

If a package has (ex:) "Features: biarch" in debian/control (like
Tollef's proposal), ppc64 buildd picks up to build this package.  If
it does not biarch capable package, it should not be built.  It
reduces much disk spaces on mirror servers, and the 90% of
non-biarch-needed (binaries and libraries) packages do not need to
consider about biarch problems.  To install both 32/64 bit packages,
we need to consider about the file duplication in /usr/share and
/usr/bin - but fortunatelly the proposal of Scott's dpkg modification,
FILTERS and CLASSES, probably fix this kind of problems.

It's very simple way and we don't modify a lot of packages.  If you
guys like this idea, I'll write the proposal to debian-devel lists.
Or is this idea already proposed?

-- gotom

Reply to: