Bug 148850
| Summary: | auto-genereting "perl Requires/Provides" causes circular dependencies | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Shekhar <shekhar.tiwatne> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | nobody+pnasrat |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-02-16 13:04:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Shekhar
2005-02-16 08:33:38 UTC
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. |