Hide Forgot
Description of problem: rpmbuild autogenerates perl module dependencies while building the rpms. This feature is useful but need some improvement. Current implementation tends to cause circular deps as shown in "Steps to Reproduce". This example is much simple but in a complex scenario (few hundred rpms) this causes a lot package installation problems. It is possible to turn these macros off while building but then you also lose some good work these macros do for you. Ideally these macros should be able to understand that <somepath>/foo.pm and <otherpath>/foo.pm are not the same and can not be treated as same dependencies. Version-Release number of selected component (if applicable): 4.0.4 or better How reproducible: Always Steps to Reproduce: 1. Build packages A and B with one sources as perl script which import module foo. Include foo.pm as well. Make sure both foo.pm goes in different paths. 2. rpm -ivh A B 3. rpm --whatrequires A 4. rpm --whatrequires B Actual results: A -> B -> A (circle) Expected results: A and B do not require each other. Additional info:
The mechanism within rpm to generate perl dependencies does little more than extract what is present in perl scripts. Any dependency loops are already present in the perl modules themselves. Override the scripts that extract the dependencies by setting, say, %__perl_requires to a wrapper script that filters out unwanted dependencies is the current practice. Expecting rpm to "just get it right" is naive for the open-ended and ever changing universe of perl scripts. One needs to fix packages case by case.
> Ideally these macros should be able to understand that > <somepath>/foo.pm and <otherpath>/foo.pm are not the same and can not > be treated as same dependencies. On the surface this statement sounds reasonable, but here is what is wrong with it. You have to consider the two sides to this problem: provides and requires. From the standpoint of provides, it would be possible to name mangle the provides such that "<somepath>/foo.pm and <otherpath>/foo.pm are not the same", the problem lies in generating a require that would map to either of these provides. Presently, and I can think of know other way of doing this across the universe of perl modules, we look for "requires" and "use" statements in perl scripts and .pm files and generate the requires from the content of the "requires" and "use" statements (think real loose scary little parser). Typically in when "requires" and "use" is used in perl, no path information is given (similar to #include in C and C++). This means the best we can do is generate a non-pathed require for the package. That said what could be improved is picking up the version info in from the "requires" and "use" in perl scripts. So we could generate something like: Requires: perl(Some::Lib) >= 2.51 But ultimately the name mangling (which is ultimately what your suggesting we do) in the Provides just can't work because we don't have that information for the generated "Requires". Also, pulling the version information for the "Requires" is quite tricky, as we would have to parse it out of things like: use Some::Lib '2.51'; use Some::Lib qw(2.51) use Some::Lib qw(2.51 symbol1 symbol2) use Some::Lib ('2.51') use Some::Lib ('2.51', 'symbol1', 'symbol2') And I am not sure that is a complete list of all the ways one can request a certain version of library or newer in perl (its very likely not with all the different ways of quoting strings and lists in perl). Someone would be more likely to look at dealing with that though than different perl libs in different paths, as one is algorithmicaly possible and the other IMHO is not.
Yeah 'Provides:' can be worked out by associating path but I am also not sure about handling 'Requires:'. But even what automated depedency is though useful in most cases but can kill some app like mine with cycles and then I need to turn this good thing off. I would also get in trouble again if rpm does this for pyrhon. I know that there are some such python autodependency generators available. So this feature is useful but with some side effects. Thanks James.