> What if you can only uninstall the package by deconfiguring another one > that you need? Take this situation: > > foo-source has > Build-Depends: gnu1 | gnu2 > Build-Conflicts: bar > > gnu1 has > Depends: bar > > Currently bar and gnu1 are installed. Will your five lines of code be > able to uninstall bar, uninstall gnu1, and install gnu2?
First: The ~ 5 lines were for additional support of negative dependencies. Second: sbuild currently doesn't support alternatives yet :-( Third: Dependency calculations et al. are passed on to apt-get, so they make up no code :-) > Hmm, lprng Provides lpr (and Conflicts with it). I guess this > expresses that lprng won't do. Ah, that sounds like an explanation, yes. Isn't this a good reason for Build-Conflicts:? A simple Build-Depends: lpr could be satisfied by lprng as well, but it's wrong since a2ps needs real lpr, not lprng. > They should be configured not to use svgalib, via options in debian/rules. > This should not depend on the build environment. (If it does, it's > far too easy to silently build without it, even on a platform that > does need it). This is the case for many, really many libs :-( It was one of the reason we've "invented" source dependencies. You simply can't hardwire all lib dependencies as options to configure. > Also a packaging bug. Bash should be told to use libncurses, > regardless of the build environment. Also if you have to patch a really correct upstream configure? (I assume there's no option for disabling libtermcap.) > (and so forth)... these should all be told to configure the right > way, regardless of build environment. Build-time configuration is > nice, but not if you want the binary package to be easily > reproducible. ...but often configure scripts aren't flexible enough so that you can select all options from the command line :-( > I've already seen far too many bugs in NMUs caused by packages > silently built with the wrong configuration. And this hopefully will come to an end with source dependencies! Roman
