Bug 674765 - new filtering macros for perl
Summary: new filtering macros for perl
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Jitka Plesnikova
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 694496
TreeView+ depends on / blocked
 
Reported: 2011-02-03 08:50 UTC by Ralf Corsepius
Modified: 2014-07-09 07:41 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-09 07:41:23 UTC
Type: ---


Attachments (Terms of Use)
Real world srpm exposing this issue (486.88 KB, application/x-redhat-package-manager)
2011-02-03 09:10 UTC, Ralf Corsepius
no flags Details

Description Ralf Corsepius 2011-02-03 08:50:06 UTC
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.

Comment 1 Ralf Corsepius 2011-02-03 09:10:32 UTC
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).

Comment 2 Panu Matilainen 2011-02-03 09:44:07 UTC
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 :-/

Comment 3 Ralf Corsepius 2011-02-03 10:09:41 UTC
(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.

Comment 4 Panu Matilainen 2011-02-03 10:58:04 UTC
(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.

Comment 5 Ralf Corsepius 2011-02-03 12:49:49 UTC
(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!

Comment 6 Panu Matilainen 2011-02-03 13:28:24 UTC
(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.

Comment 7 Ralf Corsepius 2011-02-03 15:09:01 UTC
(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).

Comment 8 Ralf Corsepius 2011-02-03 15:12:24 UTC
(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.

Comment 9 Petr Pisar 2011-02-16 17:07:44 UTC
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?

Comment 10 Panu Matilainen 2011-02-22 06:24:10 UTC
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.

Comment 11 Marcela Mašláňová 2011-06-01 13:09:05 UTC
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.

Comment 12 Fedora End Of Life 2013-04-03 19:34:14 UTC
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

Comment 13 Fedora Admin XMLRPC Client 2013-08-12 11:49:41 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.


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