Bug 148850 - auto-genereting "perl Requires/Provides" causes circular dependencies
auto-genereting "perl Requires/Provides" causes circular dependencies
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-16 03:33 EST by Shekhar
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-16 08:04:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Shekhar 2005-02-16 03:33:38 EST
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:
Comment 1 Jeff Johnson 2005-02-16 08:04:23 EST
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.

Comment 2 James Olin Oden 2005-02-16 08:49:56 EST
> 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.
Comment 3 Shekhar 2005-02-17 09:52:44 EST
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.

Note You need to log in before you can comment on or make changes to this bug.