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
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
2. rpm -ivh A B
3. rpm --whatrequires A
4. rpm --whatrequires B
A -> B -> A (circle)
A and B do not require each other.
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
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
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.