Bugzilla Bug 196627

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 an attachment (id=149954) [details]
fuse_python_accept_none.patch

Here is the patch ...

Created an attachment (id=149956) [details]
fuse-python-0.2.ebuild

And the ebuild for fuse-python

Created an attachment (id=149959) [details]
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