There are two ebuilds for python fuse binding in portage which have a file collision on /usr/lib64/python2.5/site-packages/fuse.py The weird thing is, the URL in both ebuilds is the same. Isn't this just a duplicity?
The fuse-python (0.2_pre2) seems to be a later version of python-fuse (according to the AUTHORS file)...
...and BTW, the latest version is 0.2 so you can add id to portage when handling this... ;-)
It's nice that sys-fs/python-fuse has PROVIDE="virtual/fuse-python", but it fails to block virtual/fuse-python, plus sys-fs/fuse-python does't provide the virtual at all. Please, sanitize this :)
...didn't even know there's virtual. This is IMHO nonsense. AFAIK, there is only one fuse-python implementation and even if there were more, they would be incompatible so packages would depend on individual ones, not the virtual...
(In reply to comment #4) Removing the virtual will fix the virtual as well. *g* I still don't grok why both ebuilds were added, anyway the blocker is needed. Bug 183924 Comment #4 says that sys-fs/python-fuse works much better than sys-fs/fuse-python, well no clue really. :)
I think that's because they were written for the old (0.1) version (which is called python-fuse in portage). The interface has changed meanwhile so it's logical they are now broken. Well, I don't really know that python-fuse is version 0.1, I just guess it from the versioned file it installs. Anyway, python-fuse ebuild gets the source from debian archive which is really weird. I recommend: * zapping the virtual * moving python-fuse-2.5 to fuse-python-0.1 * changing deps in appropriate ebuilds (specifying the 0.1 version) * telling to people to upgrade to new (0.2) version interface (In reply to comment #5) > (In reply to comment #4) > > Removing the virtual will fix the virtual as well. *g* I still don't grok why > both ebuilds were added, anyway the blocker is needed. > > Bug 183924 Comment #4 says that sys-fs/python-fuse works much better than > sys-fs/fus-python, well no clue really. :) >
And perhaps it should also be moved into dev-python as this is the place for the other python bindings. BTW: I wrote an email to Josh about this on 09/26/07 - and got no answer yet... Perhaps we'll get one with this bug ;)
Reassigning since jmglov has retired from Gentoo.
I would take care of this fuse-python mess (bumping the package, removing the virtual, have a look at the corresponding bugs) and maintain it. Where can I find a dev who would proxy-maintain?
Jokey, you interested in comment 9?
Yup, I take it
Necoro promised to have stuff ready by next week
Just a status update: Bug #183710 is near to be fixed. Currently there is a bug in fuse-python-0.2 in the compat layer for old API version. I already found how to fix it: Will report it upstream - and we'll see what follows :)
Ok - no further comments from either flickrfs nor fuse-python ... So I'll attach the patch and the corresponding ebuilds. The further procedure: - mask python-fuse for removal - move fuse-python from sys-fs/ to dev-python/ - bump fuse-python
Created attachment 149954 [details, diff] fuse_python_accept_none.patch Here is the patch ...
Created attachment 149956 [details] fuse-python-0.2.ebuild And the ebuild for fuse-python
Created attachment 149959 [details, diff] sys-fs/flickrfs-1.3.9 diff And here a patch for the ebuild of sys-fs/flickrfs-1.3.9. This changes the fuse-python dep to match the new category and make it depend on versions >=0.2 flickrfs is the only package having a fuse-python dependency
Should be all set now
(In reply to comment #18) > Should be all set now profiles/base/virtuals still references sys-fs/python-fuse on line 22: virtual/fuse-python sys-fs/python-fuse
(In reply to comment #19) > profiles/base/virtuals still references sys-fs/python-fuse on line 22: > virtual/fuse-python sys-fs/python-fuse $ cvs ci -m 'virtual/fuse-python is dead (bug #196627).' /var/cvsroot/gentoo-x86/profiles/base/virtuals,v <-- virtuals new revision: 1.111; previous revision: 1.110
