Re: ARMv4-support in armel/squeeze?
On Mon, Dec 20, 2010 at 7:23 PM, Konstantinos Margaritis
<markos@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.
Reply to: