Skip to content
This repository has been archived by the owner on Jan 21, 2024. It is now read-only.

release tagging and conflicting man page #11

Closed
mudler opened this issue Jun 19, 2015 · 4 comments
Closed

release tagging and conflicting man page #11

mudler opened this issue Jun 19, 2015 · 4 comments

Comments

@mudler
Copy link

mudler commented Jun 19, 2015

Hi,

i'm a Sabayon developer, and i wanted to fix the ebuild upstream for your project, but actually there is a problem:
https://bugs.gentoo.org/show_bug.cgi?id=536630

libbsd share with your project the same manpage named "funopen", thus there are conflicts while both packages want to be installed on the same machine.

Meanwhile i wanted also to update the ebuild, and noticed that ubuntu released the 1.4.6 version https://launchpad.net/ubuntu/+source/funtools/1.4.6+git150228-1 but i can't see that tag on the git repo, if you guys will tag it, it will be really helpful to make a "neat" package bump :)

Thanks for your time
👍

@ericmandel
Copy link
Owner

I added a v1.4.6 tag, as requested.

Not sure what to do about the man page name collision. I don't suppose "being there first" counts for anything!

@mudler
Copy link
Author

mudler commented Jun 20, 2015

@ericmandel thanks for the tag

for the man page: i actual don't know either what would be the best solution here, i noticed that both libs share the same function name and just warned that this causes issues when both packages wants to be installed. It's no race at all here who being there first :)
what happens here is that libbsd appears to be mostly common used as it's a reverse deps for some common packages (like xdm, ettercap, bumblebee) https://packages.sabayon.org/show/libbsd,108226,sabayon-weekly,amd64,5,standard/reverse_dependencies#package-widget-show-what , thus preventing your package installed at all in gentoo in a lot of boxes

@ericmandel
Copy link
Owner

@mudler if funtools was an actively supported package, I'd be more concerned with this conflict. But active development ended in 2007 and I only keep it in github for researchers who still use it "as is". Under those circumstances, doing nothing is probably OK. One can always grab the GitHub version in cases where the conflict arises.

@mudler
Copy link
Author

mudler commented Jun 20, 2015

@ericmandel good enough for me :) thanks for your time

@mudler mudler closed this as completed Jun 20, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants