[Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

[Panu Matilainen]

On 10/02/2017 02:14 PM, Thierry Vignaud wrote:
> On 2 October 2017 at 12:05, Panu Matilainen <pmatilai at 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.
>