The dev-libs/lsh package includes the nettle library, which conflicts with dev-libs/nettle (which I'd like to add) since they are sharing the filenames. Looking at how other distributions do it, they seem to remove nettle from the lsh build process and link against the nettle library of a real "nettle" package. Anyway, the current situation is rather broken since it blocks adding an ebuild for the nettle library (http://www.lysator.liu.se/~nisse/nettle/).
Looks like it's all yours to fix up since there's no metadata file for dev-libs/lsh.
we cant exactly 'fix' this without an ebuild for nettle first
yes, but we also can't add a nettle ebuild before this is fixed ;P The solution from what I see would be to do a new -r1 of lsh at the same time nettle is committed and nettle would need to check if the new revision is installed to not conflict with nettle (if lsh is installed at all, of course). I will soon attach a nettle ebuild to this bug.
my point was, i'm not going to change lsh unless i have a copy of the nettle ebuild
Created attachment 35183 [details] dev-libs/nettle/nettle-1.10.ebuild Proposed nettle ebuild. The ebuild assumes that >=lsh-1.4.3-r1 don't include nettle anymore
Mike, I understood what you meant :) I just wanted to say that fixing the lsh package and comitting a nettle ebuild should happen at the same time :)
oh, the eerror probably should say "... to at least this version before you can install nettle" or something like that. Anyway :)
lsh wont work with the 1.10 version of nettle ... i guess theyve changed the RSA API or some junk ... i'll fix the lsh ebuild to not install libnettle.a (it should never have anyways) and then i'll add the nettle package ... the way to do it would be DEPEND="!<lsh-1.4.3-r1" instead of the junk in pkg_setup
ok, I thought it was cool if the user gets told why he can't keep his old version of lsh ;) Since I don't use lsh, I don't know anything about the RSA API problems you mentioned.
added nettle to portage and fixed lsh
