Seeking for advice: Circular Build Dependencies.
Hi, I'm seeking for advice for how to handle this rather complicated solution. I'm packaging a large software base that builds a number of libraries and applications. In order to simplify things: - foo (source package) builds: - libfoo-dev, libfoo0, libfoo0-bin, ... - and build depends on libbar-dev - bar (source package) builds: - libbar-dev, libbar0, bar - and build depends on libfoo-dev Obviously, there are circular build dependencies, which means that neither package can be built without the other one. One solution would be to throw all sources into a big source package and build everything from that. This, however, is something that I'd really like to avoid, because one of the two packages is really large, takes hours to compile, and the whole thing would produce a really lot of binary packages. I'm therefore seeking for a solution that allows me to keep the sources separate. My first guess would be to use alternative build dependencies. However, this is problematic on the buildd network, because they will fail the build if the first alternative is not installable. Therefore, I've come up with this idea: - create a 'libbar-bootstrap' source package, which ship only headers - that builds a libbar-boostrap-dev, which in turn provides: libbar-dev - build foo against libbar-boostrap-dev - build bar against libfoo-dev - build foo again, this time against libbar-dev In my tests, it *seems* that apt indeed prefers a real package over a virtual package. I'm aware of the following drawbacks: - needs an additional source package (libbar-boostrap) and uploads - versioned depends on libbar-dev (probably?) won't work anymore My question now is: - has this approach been implemented in debian before? - do I miss something else here? Thanks for your thoughts. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa9581ka@faui43f.informatik.uni-erlangen.de
Re: Seeking for advice: Circular Build Dependencies.
On Thu, Oct 13, 2011 at 15:26, Reinhard Tartler siret...@debian.org wrote: In my tests, it *seems* that apt indeed prefers a real package over a virtual package. I'm aware of the following drawbacks: It does, but you are better of handling this as an internal detail - because it is easier/faster to try non-virtual paths first - instead of a well-defined feature. Other implementations might do it completely different… (the old sbuild solver or apt utilizing an external solver aka EDSP, …) And complains to change this behavior exist ( but i guess it's unlikely). (Think of upgrades: usually the provider of foo is the newer/better package than compared to the real package foo) Also, and that might be the biggest problem, you would be never allowed to have a versioned dependency on libfoo-dev as policy says that the behavior will be undefined otherwise. For the problem itself I have no knowledge, so just two questions: Aren't compilers in the same chicken or egg dilemma? And how will new abi/api versions handled? I assume foo2 will not build against bar1 and vice versa so you need to bootstrap again… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fdgfdkuozlebzbg553inncpy9ahgdxn3oleqtca2h-...@mail.gmail.com
Re: Seeking for advice: Circular Build Dependencies.
Hi, Le 13/10/11 15:26, Reinhard Tartler a écrit : One solution would be to throw all sources into a big source package and build everything from that. Looks like the sane solution to me. Another would be to, on the contrary, split the source packages, if possible, to completely break the loop (not possible in your simplified example, perhaps possible with the actual packages). Therefore, I've come up with this idea: - create a 'libbar-bootstrap' source package, which ship only headers - that builds a libbar-boostrap-dev, which in turn provides: libbar-dev - build foo against libbar-boostrap-dev - build bar against libfoo-dev - build foo again, this time against libbar-dev I think this rebuild step is a no go. Oh, that way madness lies. Is it necessary? Is foo fully functional when built against libbar-bootstrap-dev? Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e9702f8.2020...@free.fr
