Re: First pass all buildds before entering unstable
"Noah L. Meyerhans" <noahm@debian.org> writes:
> On Fri, Nov 21, 2003 at 12:01:37PM +0100, Goswin von Brederlow wrote:
> > Yes, lets do that. Lets drop i386 since it has no foobarf compiler
> > thats only available for m68k.
>
> Uhh, no, why not just upload foobarf with Architecture: m68k? Packages
> that nobody claims will work on a given architecture obviously shouldn't
> reflect poorly on the package or the port to that architecture.
Packages should be Arch: any if they are not special to some arch. If
your mark a package Arch: !foo and someone ports the foobar compiler to
foo the package would have to be changed yet again to include foo in
its Arch list. That makes it harder for porters and creates extra work
for the maintainer.
All scripts behave correctly with packages that are theoretically for
an arch but in fact lack the dependencies to actually build. Keep it
that way.
> In fact, what we really should do is, when determining whether to
> consider it "bad" for a package not to build on a given architecture, is
> look to see if any of its dependencies have a more specific Architecture
> than "any". If package A depends on package B, and package B is
> Architecture: X,Y,Z, then package A is also implicitly Architecture:
> X,Y,Z, even though it may claim "any" architecture.
What if it depends on A | C and a is !m68k and C is !mips?
Lets make a big chain of 10 or 20 packages all with different arch
sets. I can make the example as complex as you like. Let some of the
packages fail for some arch with no previous version ever being
build. Add some cyclic dependency chains, like foobar build-depending
on barf and barf on foobar. Put in some nice versioned depends too.
Figuring out if a package is theoretically and currently buildable for
an arch isn't trivial. apt-get doesn't even try to do this kind of
stuff for normal depends.
> > What you suppose would kill all architectures in unstable. (Well,
> > killing one could remove the offending package for another arch so some
> > would remain).
>
> No, it would not at all. Really. It would simply help to prohibit
> packages from depending on versions of another package that don't even
> build on all architectures *that they claim to support*.
Checking if a previously build version exists in archive for each arch
is a much simpler and better way to test this. This will also allow
Packages to enter sarge (because all previously build archs build) and
report build failures for archs the package is being ported to or
should be ported to at the same time.
Another thing to think about is new archs getting added.
Consider the huge backlog of packages adding debian-bsd-alpha would
create. Since its a previously unknown arch no maintainer would have
!bsd-alpha in its Arch list. Almost all packages would be stuck for
month even if most packages would build cleanly.
No, going by the "previously build" rule is the sanest approach.
MfG
Goswin
Reply to: