Description of problem: A perl package which installs a httpd-conf file, say %config(noreplace) /etc/httpd/conf.d/xxxx.conf when _not using_ perl_default_filter, it provides config(xxxx) = %version-%release when _using_ perl_default_filter, it doesn't provide such tag. Version-Release number of selected component (if applicable): rpm-4.9.0-0.beta1.5.fc15 How reproducible: Always. Steps to Reproduce: 1. write an rpm spec for a package containing %config(noreplace) /etc/httpd/conf.d/xxxx.conf 2. Build the package once without any explict filters 3. ... and once with %{?perl_default_filter} added. Actual results: - without %{?perl_default_filter}, the package provides config(xxxx) = %version-%release - with %{?perl_default_filter}, it doesn't. Expected results: Consistency. IMO, config(xxxx) either must always be provided, or never. I don't know what is intended.
Created attachment 476730 [details] Real world srpm exposing this issue The tarball is a prospective update of fedora package is was going to commit to git. Build it in mock, check its provides/requires, then remove the perl_default_filter from the spec, rebuild and check its provides/requires. Among other differences (which are to be expected), when using perl_default_filter, this package looses config(xxxx).
This is expected behavior, and happens with all existing rpm versions. The Fedora-specific filtering macros work by switching off the internal dependency generator which has numerous consequences, one of which is that config(foo) dependencies don't get generated. It also has implications on multilib as the external generator doesn't generate file "coloring". Rpm 4.9.0 has internal dependency filtering capabilities so there's no need to use to the Fedora filtering macros with their unwanted consequences, but for older rpm versions there's no good solution :-/
(In reply to comment #2) > This is expected behavior, and happens with all existing rpm versions. Err ... this leaves me rather clueless and doesn't help. > The > Fedora-specific filtering macros work by switching off the internal dependency > generator which has numerous consequences, one of which is that config(foo) > dependencies don't get generated. It also has implications on multilib as the > external generator doesn't generate file "coloring". ... do I get this correctly? You are saying: "you should not use perl_default_filter"? > Rpm 4.9.0 has internal dependency filtering capabilities so there's no need to > use to the Fedora filtering macros with their unwanted consequences, Well, the example from the attachment contradicts to what you are saying. The "expected additional deps" being seen when having removing perl_default_filter from the spec are bogus (and harmful). Such cases are more the norm than the exception with perl packages. So what do you recommend to get rid of these bogus provides/requires if not filtering? In older rpms the recommendation was to write manual filters, in recent times it was using perl_filter_default. Reopening due to lack of a solution.
(In reply to comment #3) > ... do I get this correctly? > > You are saying: "you should not use perl_default_filter"? Sort of. Like said, these Fedora-specific filters have unwanted side-effects due to using the external dependency generator mode which cannot do various things such as generating config(foo) dependencies. But with older rpm versions there simply is no good way to do what the Fedora guidelines demand. So you're stuck between a rock and a hard place. > > > Rpm 4.9.0 has internal dependency filtering capabilities so there's no need to > > use to the Fedora filtering macros with their unwanted consequences, > Well, the example from the attachment contradicts to what you are saying. Nope, I only mean that rpm 4.9.0 has built-in features which can be used to the same effect to avoid the side-effects of the current Fedora filtering system. > The "expected additional deps" being seen when having removing > perl_default_filter from the spec are bogus (and harmful). > Such cases are more the norm than the exception with perl packages. I know... > So what do you recommend to get rid of these bogus provides/requires if not > filtering? In older rpms the recommendation was to write manual filters, in > recent times it was using perl_filter_default. That's not an rpm feature, it's a Fedora-specific macro from perl-devel. What's really needed is updating the Fedora macros such as perl_filter_default to use the new rpm's features rather than working around the limitations of old, and updating the guidelines etc. > > Reopening due to lack of a solution. Like said, config(foo) dependencies not being generated when external dependency generator is used is not a bug, it's expected behavior (essentially a fundamental limitation of the external generator) -> NOTABUG from rpm point of view. For now, if you must use the Fedora filtering stuff and something actually depends on the config(foo) provides (unlikely but possible), you can add them manually. Updating the macros + guidelines is beyond the scope of this bug, lets continue the discussion on fedora-devel/fedora-packaging instead for a wider audience. There's already this thread on a very much related topic: http://lists.fedoraproject.org/pipermail/devel/2011-February/148315.html, my reply has a couple of examples on using the new, built-in filtering too.
(In reply to comment #4) > (In reply to comment #3) > > ... do I get this correctly? > > > > You are saying: "you should not use perl_default_filter"? > That's not an rpm feature, it's a Fedora-specific macro from perl-devel. Irrelevant - This BZ is not a complaint about "upstream rpm being broken" it is a complaint about Fedora's rpm being dysfunctional. > really needed is updating the Fedora macros such as perl_filter_default to use > the new rpm's features rather than working around the limitations of old, and > updating the guidelines etc. You are still not providing any solution, except that you are confirming that rpm's former bugs have been replaced with new ones, now requiring new work-arounds and causing churn - That's real progress!
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > ... do I get this correctly? > > > > > > You are saying: "you should not use perl_default_filter"? > > > That's not an rpm feature, it's a Fedora-specific macro from perl-devel. > Irrelevant - This BZ is not a complaint about "upstream rpm being broken" it is > a complaint about Fedora's rpm being dysfunctional. Feel free to reassign to perl, which is where the perl filtering macros come from. They are not part of rpm, upstream or Fedora, and rpm has no control over what macros from other packages do. > > really needed is updating the Fedora macros such as perl_filter_default to use > > the new rpm's features rather than working around the limitations of old, and > > updating the guidelines etc. > > You are still not providing any solution, except that you are confirming that > rpm's former bugs have been replaced with new ones, now requiring new > work-arounds and causing churn - That's real progress! Rpm now has a mechanism to filter dependencies without workarounds and their unwanted side-effects. That workarounds added outside of rpm need to be adjusted to take advantage of new capabilities should be pretty obvious. In the meanwhile the old workarounds continue to work exactly like they always did, with the same limitations and issues they always had. I fail to see what the "new bugs" here would be, that config(foo) provides are not generated when the perl filtering is in effect is by no means a new issue.
(In reply to comment #6) > Feel free to reassign to perl, I would have done so, but bugzilla doesn't allow me to do so. > They are not part of rpm, upstream or Fedora, and rpm has no control over > what macros from other packages do. It seems to have escaped you that these macros only exist to work-around deficiencies of rpm and only are part of perl for historic reasons. > I fail to see what the > "new bugs" here would be, that config(foo) provides are not generated when the > perl filtering is in effect is by no means a new issue. Confirmed, f14's perl_default_filter also suffers from this issue. I.e. converting packages to using perl_default_filter instead of manually written filters causes them to loose config(foo).
(In reply to comment #7) > > Feel free to reassign to perl, > I would have done so, but bugzilla doesn't allow me to do so. Just found the switch (1st set ASSIGNED on the bottom of the page, then "Component" at the top of the page becomes accessible) ... reassigning to perl.
Panu, the Release Notes for 4.9.0 does not document %__provides_exclude, %__provides_exclude_from and similar. Is there any documentation? Neither /usr/share/doc/rpm-4.9.0/*, nor http://rpm.org/wiki/ do contain it. Where can I learn how to modernize perl macros properly?
There's indeed little in the way of documentation so far. I'd suggest we live with the current filtering system for F15 and leave modernizing to F16 - perl is perhaps the thing most needing filtering, but there's more than perl to consider, and there should be opportunities to remove some common filtering needs.
I agree with Panu. Filtering macros will be mentioned in guidelines soon. https://fedorahosted.org/fpc/ticket/76 Some documentation is here: http://rpm.org/wiki/PackagerDocs/DependencyGenerator We can try run new filters with perl-5.14 rebuild.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.