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

Re: First pass all buildds before entering unstable

"Noah L. Meyerhans" <noahm@debian.org> writes:

> On Fri, Nov 21, 2003 at 12:07:41PM +0100, Wouter Verhelst wrote:
> > > It is true, but I think my point is still valid, though maybe on a
> > > different level.  If a particular language's compiler is not yet
> > > available on that architecture, then surely we won't be releasing
> > > packages containing programs written in that language on that platform!
> > > Thus, the package that needs that compiler to build can not legitimately
> > > claim an Architecture of "any".
> > 
> > Actually, it can. It is not the packages' fault that a compiler is not
> > available for that platform. Should the compiler ever be ported to a
> > given architecture, if the package did not specify "Architecture: any"
> > in its control file, there would be need for an updated package for no
> > reason other than to update the Architecture line. That's silly, because
> > it would require a recompile on all architecture, for no reason.
> To me, all you're saying is that we would end up needing some kind of
> "override" file for this.  For situations where it's known and accepted
> that one or more of a package's dependencies isn't available on some
> architecture and is going to remain that way for some time.  We can then
> let that package enter the distribution, knowing that it is not going to
> be usable on some architecture.

No, just use the same rule as with testing. If a previous version
exists for an arch a package for that arch must exist for the
candidate too.

That only leaves packages where support for some arch is dropped and
they should get stuck for some time to see if anyone will volunteer to
pick up support. If not the old package can be flushed and it works

> Most packages currently build on all architectures.  The proposal we're
> talking about is basically a way to insure that new revisions of these
> packages remain buildable on all architectures before other packages may
> depend on them.


Reply to: