Bug#539187: Patch is broken - packaging is too
Josselin Mouette wrote:
> Furthermore, it is not the role of dh_pysupport to fix broken symbolic
I think maybe I wasn't clear enough about the problem - I'm not
suggesting dh_pysupport should fix a broken symlink - I'm suggesting it
breaks a symlink that wasn't broken before :-)
Specifically, prior to the call to dh_pysupport 'site-packages' contains
the following files (I've removed the cruft from the ls -l output for
$ ls -l
lrwxrwxrwx _gv.so -> libgv_python25.so
After dh_pysupport is called, 'pyshared' has the following ...
$ ls -l
lrwxrwxrwx _gv.so -> ../../python2.5/site-packages/libgv_python25.so
In other words, dh_pysupport moves the '_gv.so' link and adjusts it so
it continues to point to 'libgv_python25.so' in site_packages. However
it then proceeds to also move 'libgv_python25.so' to pyshared and this
breaks the link.
The intent of my patch is to check if the link destination is in the
same directory as the link (i.e. both in site_packages) and just do a
plain 'os.renames' on the link if it is, on the assumption that the link
destination will also be moved and will end up in the same directory
I don't quite see how running dh_link before dh_pysupport will help here
... I suppose I could delete the link prior to calling dh_pysupport and
then recreate it with dh_link in all the pyshared/python2.X directories
afterwards ... but it just seems to me that this is something that
dh_pysupport should be able to do for me, and of course it worked prior
to the introduction of the 'rename_subtle' function (in 1.0.3 I think)
> Also note that the package should be named python-gv instead.
Well it's not my package - although I have expressed an interest in
adopting it, which is why I thought I'd have a poke at the bug reports...
If I end up taking it on, I'll look into renaming it ;-)