On 10/02/2017 02:14 PM, Thierry Vignaud wrote:
On 2 October 2017 at 12:05, Panu Matilainen <pmati...@redhat.com> wrote:
It looks like some dep generators are no more run:
We've one dep generator carried by another pkg (so unchanged).
But since we upgrade to 4.14, those deps are no more run:
$ cat /usr/lib/rpm/fileattrs/perl_from_meta.attr
%__perl_from_meta_requires %{_rpmconfigdir}/mageia/perl.req-from-meta
%__perl_from_meta_path /(META.json|(MY|)META.yml)$
$ rpm --eval %{_rpmconfigdir}/mageia/perl.req-from-meta
/usr/lib/rpm/mageia/perl.req-from-meta
$ ll /usr/lib/rpm/mageia/perl.req-from-meta
-rwxr-xr-x 1 rpm rpm 1428 Her 2 10:35
/usr/lib/rpm/mageia/perl.req-from-meta*
$ rpmbuild -bb --define "_topdir $PWD" --define "_tmppath
$PWD/BUILDROOT" --without build $PWD/SPECS/perl-Term-Clui.spec
--rpmfcdebug -v -vv
(...)
D: execv(/usr/lib/rpm/mageia/perl_base.req) pid 20465
D: waitpid(20465) rc 20465 status 0
D: execv(/usr/lib/rpm/mageia/perl_base.req) pid 20467
D: waitpid(20467) rc 20467 status 0
D: execv(/usr/lib/rpm/mageia/perl_base.req) pid 20469
D: waitpid(20469) rc 20469 status 0
D: execv(/usr/lib/rpm/perl.prov) pid 20471
D: waitpid(20471) rc 20471 status 0
D: execv(/usr/lib/rpm/perl.req) pid 20474
D: waitpid(20474) rc 20474 status 0
D: execv(/usr/lib/rpm/mageia/perl_base.req) pid 20475
D: waitpid(20475) rc 20475 status 0
D: execv(/usr/lib/rpm/perl.prov) pid 20477
D: waitpid(20477) rc 20477 status 0
D: execv(/usr/lib/rpm/perl.req) pid 20480
D: waitpid(20480) rc 20480 status 0
^so perl.req-from-meta is no more run, only other scripts
(...)
3
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/lib/perl5/vendor_perl/5.26.1/Term/Clui/FileSelect.pm
Perl5 module source text [perl_base,perllib]
R perl-base >= 2:5.26.1
P perl(Term::Clui::FileSelect) = 1.710.0
R perl(Exporter)
4
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui
directory [none]
5
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/Changes
ASCII text [none]
6
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/META.yml
ASCII text [perl_from_meta]
7
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/MYMETA.yml
ASCII text [perl_from_meta]
^ so fileattr did matched but the corresponding generator was not run
(missing in above execve() list)
Any idea?
It's probably this:
https://github.com/rpm-software-management/rpm/commit/816c7cf3fdae5c45de02a42a2245549778e2ca80
If so, the following in the spec should work around it:
%undefine __global_requires_exclude_from
%undefine __global_provides_exclude_from
That works but that not manageable for 3000+ perl packages
So that would have to be reverted at the distro wide level.
I wasn't suggesting you do it on every package, it was just to see
whether that's really the cause.
Just comment out the defaults in rpm's main macros file to stop it
distro-wide.
I never really agreed to filtering doc dependencies because there's no
reason docs could not have dependencies, they just tend to be slightly
different from other docs.
Oops, that paragraph got garbled (was in a bit of hurry). It was
supposed to say something like "..., they just tend to be slightly
different in nature from other dependencies.
I understand the reasoning.
Not sure which reasoning you mean :) Like said, I never really liked the
idea of filtering them in the first place.
In that case I guess we could package them in another place (like pythoneggs)
But that means more changes to 3000+ packages.
Up to now, mga perl packagers could just rely on using "%doc META.yml"
and voila autodeps were automagically working
Just wondering if those files should really be %doc - I've no idea what they
do, but metadata doesn't really sound like documentation. Does the package
work if installed with --nodocs?
Yes, of course they would work.
Those files are not packaged in eg FC
They're just metadata. But those metadata actually describe the deps.
Yeah I get that. Let me put it in different way:
Would there be an actual reason to package those files if not for rpm's
dependency generator? This kinda sounds like the answer is "no".
- Panu -
Some distro rely on manually inserting the proper "BuildRequires",
"Requires:", "Recommend" & the like
Other (such mas mga) rely on autogenerating deps based on the deps
described in the perl package
(hint for a future feature for eg: fc29... :-) )
Like mga relied on pythoneggs before it got upstreamed as pythonX.Ydist(foobar)
And now other distro do too.
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
