private so provides filtering...

[Chris Weyl]

On Mon, May 25, 2009 at 8:49 AM, Stepan Kasal <skasal at redhat.com> wrote:

> Hello Chris,
>
> > >> > http://fedorapeople.org/~cweyl/macros.perl<http://fedorapeople.org/%7Ecweyl/macros.perl>
> <http://fedorapeople.org/%7Ecweyl/macros.perl>
> > >> [snip]
> > >> > 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.
>
> first, I'd like to join the "wonderful" chorus, both for starting
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-perl-devel-list/attachments/20090525/08bcbec8/attachment.htm>