On Mon, Dec 20, 2010 at 7:23 PM, Konstantinos Margaritis <mar...@genesi-usa.com> wrote: > Also, It should be a fix in the policy that NO package should ever be > allowed to have circular dependecies. Without a change in the policy > the problem will never be fixed.
a simple change to debian policy and thence to dpkg-buildpackage and also to the ftp site should a) prevent a package from even being _built_ which has circular build dependencies b) prevent a package which _has_ been built (presumably by utilising an older version of dpkg-buildpackage "pre-policy-change") from ending up in the archive. the thing that i find particularly puzzling / eye-opening is that gentoo, macports (darwinports) and openembedded simply don't have this problem (don't know about fedora) so there are definitely places to look, to compare their source-packages with the debian equivalents, find out what their build dependencies and their build solutions are, and, rather than have to re-learn them for debian, simply copy them. certainly in the case of the cross-compiler jobbies, the "solution" is to have a "native" version of the package which is utilised to perform a compile. i've seen this repeatedly in openembedded and one example is gtk-based applications (python-gtk, python-cairo) - even the build dependencies for "gtk" itself in fact include "gtk-native" !! the reason for this is very simple: you need the gtk building stuff in order to build parts of gtk. silly, really, but there you go. webkit is the same: you need "native" versions of bison and flex. etc. etc. but this is sliiightly different from the utterly insane and bizarre situation which konstantinos is describing, where you can only get to the other side of this circular and *native* build dependency situation by... well... you can't, basically. what was that one you told me about - avahi depending on networkmanager which depends on something else which depends on avahi? i thought that was particularly funny. how the bloody hell anyone manages to actually build _anything_ on debian correctly for these circularly-dependent packages and not screw things up due to version conflicts in libraries and header files i _really_ don't know! :) l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=tnhf2nfopppzyk+yngurdgvsr5o3-zkaxv...@mail.gmail.com
