On Mon, May 25, 2009 at 8:49 AM, Stepan Kasal <skasal@xxxxxxxxxx> wrote:
I definitely agree. However, there are a couple reasons I'd suggest we start here:
1) start simple, and prove that there's a need/demand for it.. Heck, we might find a change we need to make; this is much easier to do if we start out owning it.
2) the maintainers of the rpm package has historically been resistant to putting in place any sort of default filtering, or making the filtering process easier. (see any one of a half-dozen or so bugs, everything from the results of the prov/dep scripts[1] to not scanning private libs for prov[2], to a more aggressive "file" causing bits in _docdir to be scanned[3], to not wanting to alter _docdir scanning[4]... and those are just the ones I've filed). If we're going to get these macros into the base rpm package, which I agree is a good direction to go, I believe we're going to need to have a pretty solid base using them first.
Also, just because we'd be delivering them in a "macros.perl" file doesn't mean that their usage would be limited to just perl packages: perl is in every buildroot and on every system, AFAIK. Those macros will always be available to any system; and for the most part should be invoked conditionally anyways.
Yep. And would certainly make life easier for a bunch of people :)
A good idea, but one that the rpm maintainers have historically resisted. I don't think we should wait to solve our problems on this; if anything it sounds like an effort that could be carried on in parallel.
For our packages, we should skip any provides of the .so's in vendorarch/archlib as the perl dependency resolution will never make use of these... And nothing else on the system should, either.
Agreed, but see above :) Let's solve our problems, then get them in core rpm... Given the historical trend of rpm resisting any efforts along these lines, I think we have to do it this way to be successful.
Yeah, I'd like that too. There are a couple factors in favor of the current proposed implementation:
It works.
rpm macros are a royal pain, and keeping it simple is best for our collective sanity.
And... so we have a couple extra forks at the end of an rpm build process. Big deal :) It's not like this is either time-critical or is going to execute more than once per package build; the simplicity gained from this approach far outweighs any negative from the additional processes.
For instance, in the current implementation I could easily add additional filtering while still using the base "default" macro, without having to worry about making sure everything fits under one grep... The net result of each "filter" macro invocation is cumulative, simple, and easy:
%filter_from_requires /^perl(DBD::Pg)$/d
%perl_default_filter
What if we decided at some point to allow perl to be used to do the filtering? Or needed extra options passed to grep? (as we do for the PCRE that is the perl_archlib statement) RPM macros and filtering are painful enough. Let's just use a set of simple and effective macros that "Just Work" and we don't have to spend a ton of brain cycles on :)
That being said, I'm open to looking at any alternative set of macros :)
As to _docdir being skipped outright by base rpm: I don't think that's going to happen, ever. I think it's the right thing to do, but I don't get to make those calls and it's been repeatedly shown that it's not going to happen.
Hello Chris,
> >> > http://fedorapeople.org/~cweyl/macros.perl<http://fedorapeople.org/%7Ecweyl/macros.perl>
> >> [snip]first, I'd like to join the "wonderful" chorus, both for starting
> >> > If the macros look sane, I'll open a RFE bug against the perl package to
> >> > ask that it be bundled and delivered as /etc/rpm/macros.perl.
this topic and for going the direction towards more general solution.
But I think that the requirements are generally useful, they
shouldn't be limited to perl packaging.
I definitely agree. However, there are a couple reasons I'd suggest we start here:
1) start simple, and prove that there's a need/demand for it.. Heck, we might find a change we need to make; this is much easier to do if we start out owning it.
2) the maintainers of the rpm package has historically been resistant to putting in place any sort of default filtering, or making the filtering process easier. (see any one of a half-dozen or so bugs, everything from the results of the prov/dep scripts[1] to not scanning private libs for prov[2], to a more aggressive "file" causing bits in _docdir to be scanned[3], to not wanting to alter _docdir scanning[4]... and those are just the ones I've filed). If we're going to get these macros into the base rpm package, which I agree is a good direction to go, I believe we're going to need to have a pretty solid base using them first.
Also, just because we'd be delivering them in a "macros.perl" file doesn't mean that their usage would be limited to just perl packages: perl is in every buildroot and on every system, AFAIK. Those macros will always be available to any system; and for the most part should be invoked conditionally anyways.
The requirement to skip %{_docdir} seems safe for all packages.
Yep. And would certainly make life easier for a bunch of people :)
Skipping perl_vendorarch/.../*.so doesn't sound much general, but I
believe we could change that rule: auto-provides should count only
"lib*.so" libraries, not all "*.so".
A good idea, but one that the rpm maintainers have historically resisted. I don't think we should wait to solve our problems on this; if anything it sounds like an effort that could be carried on in parallel.
For our packages, we should skip any provides of the .so's in vendorarch/archlib as the perl dependency resolution will never make use of these... And nothing else on the system should, either.
I think we should really push these changes to the rpm package itself
(or at least to redhat-rpm-config).
Agreed, but see above :) Let's solve our problems, then get them in core rpm... Given the historical trend of rpm resisting any efforts along these lines, I think we have to do it this way to be successful.
I'm not much happy with the actual implementation in macros.perl:
We should not build a pipe of grep commands; one grep in a pipe is
enough. Moreover, the %{_docdir} subtree should be skipped by find
in the first place (-prune is your friend).
Yeah, I'd like that too. There are a couple factors in favor of the current proposed implementation:
It works.
rpm macros are a royal pain, and keeping it simple is best for our collective sanity.
And... so we have a couple extra forks at the end of an rpm build process. Big deal :) It's not like this is either time-critical or is going to execute more than once per package build; the simplicity gained from this approach far outweighs any negative from the additional processes.
For instance, in the current implementation I could easily add additional filtering while still using the base "default" macro, without having to worry about making sure everything fits under one grep... The net result of each "filter" macro invocation is cumulative, simple, and easy:
%filter_from_requires /^perl(DBD::Pg)$/d
%perl_default_filter
What if we decided at some point to allow perl to be used to do the filtering? Or needed extra options passed to grep? (as we do for the PCRE that is the perl_archlib statement) RPM macros and filtering are painful enough. Let's just use a set of simple and effective macros that "Just Work" and we don't have to spend a ton of brain cycles on :)
That being said, I'm open to looking at any alternative set of macros :)
As to _docdir being skipped outright by base rpm: I don't think that's going to happen, ever. I think it's the right thing to do, but I don't get to make those calls and it's been repeatedly shown that it's not going to happen.
To sum up, I'd like to push the actual filters to rpm build defaults,
but I'm not so sure about pushing the general mechanism to amend the
filter macros.
Hey, we have to start somewhere :) Every interaction I've seen or read with the rpm maintainers leads me to believe that they're not going to want this in base rpm without a hugely compelling reason first... "we need it" and "the current methodology is broken" not being compelling reasons :)
-Chris
[1] https://bugzilla.redhat.com/show_bug.cgi?id=456357
[2] https://bugzilla.redhat.com/show_bug.cgi?id=487972
[3] https://bugzilla.redhat.com/show_bug.cgi?id=473874
[4] https://bugzilla.redhat.com/show_bug.cgi?id=463461, https://bugzilla.redhat.com/show_bug.cgi?id=234691
--
Chris Weyl
Ex astris, scientia
-- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
