Summary: | x11-terms/eterm has an unresolved dependency to dev-libs/libpcre, likely upstream | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tom Fredrik Blenning Klaussen <bfg-dev> |
Component: | New packages | Assignee: | SpanKY <vapier> |
Status: | VERIFIED FIXED | ||
Severity: | minor | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Tom Fredrik Blenning Klaussen
2003-12-25 07:32:41 UTC
libast links against libpcre and thus eterm links against libpcre ... but this only happens if you have libpcre on your system ... you must have had libpcre on your system at some point, emerge libast/eterm, then later unmerged libpcre ... So what you're saying is that this problem should be adressed by the people in charge x11-libs/libast? I looked up the metadata.xml file. And ther maintainer there is also you. Shouldn't x11-libs/libast have a dependency to dev-libs/libpcre then? what i'm saying is you had libpcre on your system, then you emerge libast/eterm, then you removed libpcre, and BAM eterm stopped working thus the 'bug' is user generated and cant really be accounted for I'm a little afraid of being to quarrelsome, so you just say so if you find this discussion unrewarding. It's after all a minor bug, that we both know how to workaround. I'm in no way denying that I removed libcre, but that's because I was running depclean. Now, it's my opinion that also depclean should work fine within the system, so something is wrong when it's broken. (Of course I ran it at my own peril after receiving so explisit warnings, but still it's intended to work.) Basically what you are saying is that 'libast' finds 'libcre' on the system during it's configure run, and thereby decides to link with it? If this is the case, a run time dependecy has been created from within the build, this dependency is of course not static, but rather what I would call a "dynamic dependency". I would say that it's a valid claim that some form of dependency is created upon this occurence. I suspect your response to this would be something along the lines of: This is a sort of dependency, that isn't supported by portage. So basically what we are dealing with is a design flaw (not a bug) in the portage system? - And some kind of field like a "post build dependancy" should have been created. Do you agree? I'm sorry for putting words in your mouth, just trying to speed up the discussion a little bit ;) you never mentioned that you ran depclean :) to me, it sounded like you ran `emerge unmerge libpcre` and then filed a bug when things broke ... i added libpcre as an optional DEPEND to libast so in the future, depclean shouldnt try to remove it on you fixz0red Hmm, had I run 'emerge unmerge libpcre' and filed a bug, I should have my head decapitated ;) It's not the first time I've neglected to tell things, and caused misunderstandings, sorry for that. Anyway, I was on a little run to verify all my former bugs, and I couldn't see that the fix was applied. weird, the file was still sitting in my CVS but never had been committed ... sorry about that Well then it seems like depclean no longer opts to remove libinc. I'm happy :) Closing this bug now. |