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

Bug#498300: specify that architecture-specific dependencies must have a non-empty list of architectures



On Mon, Sep 22, 2008 at 11:46:41PM -0500, Gunnar Wolf wrote:
> Stefano Zacchiroli dijo [Fri, Sep 19, 2008 at 01:46:05PM +0200]:
> > As per policy the empty architecture list has no defined semantics, I
> > guess that the only possible behaviours out there are the following:
> > 
> > 1) require at least one entry (as did by python-debian)
> > 
> > 2) assume a default polarity, this in turn would lead to one of the
> >    possible two semantics:
> > 
> >    a) (polarity positive) hence empty arch list means "no architecture",
> >       i.e. useless dependency
> > 
> >    b) (polarity negative) hence empty arch list means "no excluded
> >       architecture", i.e. always present dependency
> > 
> > We can start betting on this possibilities :-)
> 
> Umh... And I think I'd rather go with the negative polarity. This
> means that [] is a no-op. Positive polarity just kills all the
> dependency information for that dependency... And I doubt it is ever
> desirable! 

I don't know. It seems to me that the most likely reason for this is a
substitution gone wrong, for example a debian/control.in file that looks
like either:

  Build-Depends: foo [@FOO_ARCHES@]

or:

  Build-Depends: foo [@FOO_EXCLUDED_ARCHES@]

While I agree the latter is quite plausible, I can also easily imagine
the former: for example, you remove the last of the lines that looks
like "FOO_ARCHES += i386" from debian/rules and forget that it's now
empty.

I don't think tools can reasonably guess this, and I'd prefer it if they
simply rejected it up-front rather than trying to guess at a useful
meaning for something that's clearly a mistake.

-- 
Colin Watson                                       [cjwatson@debian.org]



Reply to: