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

Re: Circular Build-Depends; am I their only enemy?

viro@parcelfarce.linux.theplanet.co.uk writes:

> On Sat, Nov 01, 2003 at 04:38:49PM -0700, Joel Baker wrote:
> > I like this solution. In fact, I like it a lot. (Of course, I also like
> > the concept that Debian main in stable and testing should be closed sets,
> > in terms of build-dependancies). I'd love to see a Build-Recommends for,
> > say, texinfo or emacs (yes, we have things that Build-Depend on emacs...)
> > if all they're being used for is documentation that *should* be there in an
> > official package going to ftp-master, but which isn't crucial to skip if
> > you're, say, building it solely to be able to build emacs...
> FWIW, we might be better off with per-target build-depends and something
> along the lines of having minimal-gcc that would
> 	* provide c-compiler
> 	* include no *.info, etc.
> 	* have minimal build-depends - with no dependencies on texinfo, let
> alone the stuff needed only for Ada/Java/whatnot.
> 	If the set of packages could be layered, so that layer 0 would
> consist of build-essential ones and have build-depends possible to satisfy
> within itself and layer n+1 would have build-depends possible to satisfy
> within layers 0--n...

Layer 0 is base + build-essential.
Layer 1 is everything without Build-Depends.
Layer 2 is everything only Depending on Layer 1

Get your layers on the fly.

> 	As for the packages that depend on themselves...  Either they
> *can* be built with standard tools, in which case you can have something
> along the lines of

Depending on yourself is very evil. Especially when you mix binary-any
and binary-all packages with versioned Build-Depends.

A few packages have become actually unbuildable because they where
uninstalable. Its a pain to force build the stuff by hand and hope the
forced build is sane enough to rebuild itself.

> Binary: foo-bootstrap, foo
> Build-depends: <common stuff>
> Build-depends[foo-bootstrap]: <what's needed for bootstrap build>
> Build-depends[foo]: foo-bootstrap
> with foo providing foo-bootstrap
> or you simply can't build the sucker without itself anymore, in which case
> it either should be accepted as part of toolchain (which shouldn't be done
> easily) or it should be dropped from the very beginning.
> Again, see the story of pm3 eviction...

I've seen and manually fixed 3 or 4 package being stuck on
autobuilders due to circular depends with version conflicts. Mostly
its because binary-all packages get removed from archive for all archs
as soon as the new one enters. Versioned depends make packages
uninstallable all the time and combined with a circular Build-Depends
the package becomes unbuildable too.


Reply to: