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

Re: Build-Depends-Indep and packages with architecture all



On Fri, Aug 01, 2003 at 09:57:10AM +0200, Frank Küster wrote:
> Joel Baker <fenton@debian.org> schrieb:
> 
> > On Thu, Jul 31, 2003 at 04:54:42PM +0200, Frank Küster wrote:
> >> Hi,
> >> 
> >> for practice and because I want to use it, I am working on a package of
> >> the CVS version of auctex, a LaTeX mode for Emacs. Since it's only an
> >> Emacs-addon written in Lisp, it's of course architecture independent. 
> >> 
> >> In debian/rules of the "real" package from unstable, binary requires
> >> binary-arch and binary-indep; the first does nothing and the second
> >> builds the package.
> >> 
> >> In the original package's control file, there is a line of
> >> Build-Depends-Indep, but no Build-Depends. Does this make sense for a
> >> source package that has no architecture dependent binary packages at
> >> all? Why not just use Build-Depends here and use Build-Depends-Indep
> >> only when a source package yields both kinds of binary packages?
> >
> > Because it is simpler to have two easily expressed rules ("Build-Depends
> > must be satisfied for <X> targets", "Build-Depends-Indep must be
> > satisfied for <Y> targets") than a complex set of exceptions
> > ("Build-Depends must be satisfied for <X> on Arch: (!= all), or <Y> on
> > Arch: all, unless Build-Depends-Indep is also set, in which case....")
> 
> That sounds sensible. However, I'm puzzled by the following statement in 
> 
> file:///usr/share/doc/debian-policy/policy.html/ch-relationships.html#s7.6
> 
> ,----
> | Build-Depends, Build-Conflicts 
> |
> | The Build-Depends and Build-Conflicts
> | fields must be satisfied when any of the following targets is invoked:
> | build, clean, binary, binary-arch, build-arch, build-indep and
> | binary-indep.
> `----

Hmmm. I'm not sure if that needs to be updated, or if I've just missed
something. Practice may be preceeding policy, however...

> So if I put all the dependencies into Build-Depends for a package that
> only generates a single package_version_all.deb, I get the same effect
> as if I put only some (like debhelper) there and the rest into
> Build-Depends-Indep. Or am I missing something?

It might work, given the above; it's still better style, if nothing
else, to use the BDI field for stuff that is needed when invoking the
build-indep/binary-indep targets (for example, latex2html or somesuch, for
generating docs for a foo-doc*_all.deb package)

> > 6 extra characters in the control file is a small price to pay for sanity,
> > especially because it allows some of us (namely, porters) to build *simple*
> > tools that figure out dependancy trees, and which can prune some parts of
> > them based on this information.
> 
> What concern do porters have with architecture-all-only-packages?

With most Arch: all packages, little to none. The concern is actually in
*not* having stuff that is *only* needed for -indep targets (which will
generally never be built by porting machines) in the Binary-Depends field,
so that it doesn't get installed (since it won't be needed). Or, in the
case of bootstrapping ports, so that they don't avoid building the package
thinking it needs emacs ported first, when really emacs is only used to do
some documentation fudging.

Yes, there are things in the archive which BDI on emacs...
-- 
Joel Baker <fenton@debian.org>

Attachment: pgpfcGa6FSR1Z.pgp
Description: PGP signature


Reply to: