Re: fakeroot a solution for multi-architecture building?
On Fri, 26 Sep 1997, Christoph Lameter wrote:
> We have the problem of keeping packages up to date in multiple
> architectures. A i386 package is updated and then the maintainers for
> other architectures have to download the package and manually build it for
> the other architectures.
> With fakeroot there is a way to securely build packages without
> risking some trojan horse in the debian/rules or similar things.
> Maybe we have a chance here to make sure packages are available in
> all architectures ASAP after the initial release by the primary
> maintainer.
We've been discussing this on the debian-alpha list and I'm sure this has
gone on in the other ports as well....
Fakeroot looks like the answer to the multi-architecture packaging
problem, as long as it's secure. I was waiting for the problems to be
resolved with it before trying it out, but went on vacation and missed out
on the latest status of fakeroot. Has it been resecured again?
> 1. We have a list of machines that are able to build packages
> on i386, alpha, sparc and m68k. These are equipped with tools for
> for automatic package building.
> 2. As soon as a package is moved into the dist by Guy it is
> checked if it is has already been ported to other architectures
> in prior releases. (A list of packages that can automatically
> be build for other architectures essentially)
This is a good idea. We were thinking of just having it automatically try
to compile it anyway, since often new upstream releases break some of the
previously added support anyway. That way, those new packages that will
work out-of-the-box will be compiled and packaged regardless of whether or
not a port has been tried in the past. Those that fail will follow the
procedures below. Also, in the interim, if an automated packaging
solution isn't available but a decent machine (say an alpha) is available
on the net with fakeroot installed, the original maintainer can try to
hand-package it.
> 6. On failure an automated bug report is filed against the package with
> the output of the failed build.
Additionally, I thought about what happens if the maintainer runs into an
architecture-specific problem that he/she can't solve. My idea is to set
up an additional devel list for each architecture (since there aren't
many, it should be low overhead). Anyone with knowledge of the specifics
of the architecture in question could join the lists and offer support in
those cases. This would allow a maintainer to have access to a pool of
knowledge in case of problems.
> Certainly not all packages will work that way but we could work on
> perfecting this system for all packages so that all architectures
> are always up to date. If a primary maintainer does some changes
> that break other architectures then he will get a bug report immediately
> and can fix things.
> We need to begin with a small list of packages that are gradually
> expanded.
I'm about to submit alot of patches to package maintainers regarding the
Alpha port. Once those are incorporated and the final packages are on
master, we can get a good grasp on just how much work may be involved with
multi-architecture support. My guess is that the maintainers who work on
more than a few large packages may feel overloaded since some of the
changes are quite extensive.
Chris
------------------------------------------------------------------
Christopher C. Chimelis chris@classnet.med.miami.edu
Systems Supervisor
Division of Biomedical Communications
University of Miami School of Medicine
--> finger chris@classnet.med.miami.edu for PGP public key <--
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: