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

Bug#191411: [proposal] build-depends-indep should not be satisfied during clean target



On Mon, Jun 09, 2003 at 10:59:18AM +0100, Julian Gilbey wrote:
> On Fri, Jun 06, 2003 at 06:31:31PM +0200, Bill Allombert wrote:
[...]
> > > Wouter Verhelst <wouter@grep.be> writes:
> > > > I therefore propose the following change to section 7.6, which is a
> > > > partial rollback from #164035:
> > > > 
> > > >       `Build-Depends-Indep', `Build-Conflicts-Indep'   
> > > >            The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must
> > > >            be satisfied when any of the following targets is invoked:
> > > > +          `build', `build-indep', `binary' and `binary-indep'.
> > > > -          `build', `build-indep', `clean', `binary' and `binary-indep'.
[...]
> > Note that this policy change make a difference for
> > arch: all source packages. For them, it is currently equivalent
> > to use 'Build-Depends-Indep' and 'Build-Depends'
> > 
> > With this change, it will no more be the case. Build-Depends will
> > be safer since it cover clean (this trigger a lintian warning
> > currently).
> > 
> > It can be worthwhile to state explicitly what happen for source
> > arch:all packages in the policy.
> 
> He's right.  Lots of Arch: all packages (correctly) use
> Build-Depends-Indep and not Build-Depends at all.  With this change to
> policy, almost all of them will immediately cease being policy
> compliant.  (Most have debhelper as a dependency in the clean target.)
> So what should this policy be?  I understand the desire not to require
> Build-Depends-Indep to clean, but this isn't quite the way to do it
> properly.
> 
> Any ideas?

How about something that conveys the following intent:

  * If a package has only Build-Depends:, or both Build-Depends: and
    Build-Depends-Indep:, then Build-Depends: must be satisfied for
    clean.

  * If a package has only Build-Depends-Indep:, then
    Build-Depends-Indep: must be satisfied for clean.

It's less elegant by some way, but does seem to be roughly what people
want and still compatible. Does it have any downsides?

  `Build-Depends-Indep', `Build-Conflicts-Indep'
       The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must
       be satisfied when any of the following targets is invoked:
       `build', `build-indep', `binary' and `binary-indep'. In addition,
       if either the `Build-Depends' or `Build-Conflicts' field is not
       present, the respective `-Indep' variant must be satisfied when
       the `clean' target is invoked.

Alternatively, we could just special-case source packages that only
generate "Architecture: all" binaries and say that they need to satisfy
Build-Depends-Indep: for clean. So:

  `Build-Depends-Indep', `Build-Conflicts-Indep'
       The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must
       be satisfied when any of the following targets is invoked:
       `build', `build-indep', `binary' and `binary-indep'. In addition,
       if the source package only generates `Architecture: all' binary
       packages, they must be satisfied when the `clean' target is
       invoked.

I'm not sure which of these is better. The first probably has more weird
corner cases, but on the other hand I'm not sure they're relevant in
practice, and it's probably simpler to implement and understand.

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Reply to: