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.
MfG
Goswin
Reply to: