Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
--- Comment #14 from Jorge A Gallegos <kad(a)blegh.net> 2012-01-19 01:06:05 EST ---
(In reply to comment #12)
That anchor does not exist, but I believe this case
what would apply here. The only reason I am setting the Conflicts flag is
because the binaries actually clash, both are installed as /usr/bin/s3fs. It
suggests using either alternatives or environment modules to alleviate this. I
have a question tho, would installing this new binary as /usr/bin/fuse-s3fs (or
similar) be an acceptable workaround? this program hasn't been packaged in
either arch, debian or ubuntu (I searched in all). I believe this would be the
first "official" package of said software. If that is an acceptable workaround
I can even propose that when contacting upstream, it would basically be a
"heads up, guys" and see if they are happy with it.
Could you sort out the "Conflicts" by getting in contact with Neil Horman (
) and the developers of this s3fs software?
I will contact Norman and the guys from google code's s3fs and see what I can
find out. Historically, the google code's take on s3fs would get to keep the
name since Norman's version came up later (there's mention of that project in
the fedorahosted page). There was even a third one that went nowhere
That web page already comments on the potentially conflicting naming, but if
the conflict cannot be resolved, it will be necessary to talk to the
Fedora Packaging Committee:
There has been a new release of fuse-s3fs recently, btw, so one cannot claim it
would be dead: http://koji.fedoraproject.org/koji/packageinfo?packageID=5960
That is probably because of this recent thread:
I would note that http://code.google.com/p/s3fs/source/list
looks more active
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.