[Rpm-maint] [PATCH] add support for scriptlet deps in generated deps

[Jeff Johnson]

> On Sep 13, 2018, at 7:21 AM, Panu Matilainen <pmatilai at redhat.com> wrote:
> 
>> On 9/13/18 12:38 PM, Thierry Vignaud wrote:
>> Le mer. 12 sept. 2018 à 19:15, Neal Gompa <ngompa13 at gmail.com> a écrit :
>>>>>> In Mageia, we eg had:
>>>>>> 1) manual "requires(post)" or "requires(posttrans): info-install"
>>>>>>     (info-install being the package containing /sbin/ /sbin/install-info
>>>>>> 2) plus manual %post or %posttrans calling install-info
>>>>>> 
>>>>>> This was a manual process, so it was sometimes missed in some pkgs.
>>>>> 
>>>>> 
>>>>> That's why Fedora switched to transfiletrigger. It is much better ;)
>>>> 
>>>> But we still need the pkgs container the info files to require the
>>>> needed /sbin/info-install
>>>> 
>>>>>> We've replaced those manual requires+scriptlets by a filetrigger.
>>>>>> But we still want info-install to be installed, so in order to replace
>>>>>> the manual requires, we want to automatically emit the requires on
>>>>>> info-install
>>>>>> But we don't want to emit "requires: info-install",
>>>>>> what we want really is "requires(posttrans): info-install"
>>>>>> 
>>>>>> The patch enables to emit requires for scriptlets or filetriggers.
>>>>> 
>>>>> 
>>>>> This is too specific use case I think..
>>>> 
>>>> That's an example but there could be more
>>> 
>>> I think the idea usually is that the file trigger would not fire if
>>> the package isn't installed, so forcing a dependency here means that
>>> there was no benefit to separating it out to be run only when it was
>>> needed. It basically makes it impossible to avoid running the trigger.
>> Which is exactly the point here:
>> Again, here the policy was for all those pkgs to require info-install
>> & run it in %post or %posttrans
>> In order to ease packager work, we replaced this manual work by using
>> a filetrigger.
>> But we stil want info-isntall to be installed, hence this patch
>>> In the case of info, there's no point in running the info commands if
>>> info itself is not installed. You can't use them anyway. :)
>> Again, info-install was manually required before, we just want to automate that.
> 
> But you don't need scriptlet context dependecies for that.
> 
> There's actually a more generic issue behind this: content viewer applications. You'll want an info-viewer for texinfo pages, a man page viewer for man pages, a browser for html content etc.
> 
> I've occasionally played with the idea of generating viewer(mimetype) style dependencies. Traditionally no such dependencies have been generated because it is a bit dubious - "every system will have man installed", right, and same for "info"? And if not then maybe it's for a reason, such as wanting a minimal disk usage and install was done with --nodocs, in which case dragging the viewer in would be highly counter-productive. It should be a soft dependency if anything at all.
> 
> Info only differs from man in that there's a central registry that needs updating, but that does bring up an interesting question: there are multiple alternative viewer applications but only install-info from info itself can maintain the registry. So where does the dependency on the package containing the trigger script (and install-info) belong?
> 
> After a bit of thought over lunch, I think it actually belongs in the viewers: as long as nobody wants to view those info files, there's no need to maintain the registry. Once you install a viewer, that changes. But as long as the viewers drag in the package with the trigger (so in this case "info"), the trigger will run on the viewer installation and register all the files already on disk.
> 

Here's a minority, contrarian POV:

Running cache/index rebuilds -- ldconfig, fonts, XML, etc -- should be implemented in rpm, implemented through a different mechanism than triggers.

Too much time and effort has been spent arranging dependencies and mechanisms in packaging for what is ultimately simple and obvious tasks.

With multiple (3 if you include rpm5) file trigger implementations, designing a common representation and mechanism is almost impossible.

*shrug*

73 de Jeff
>    - Panu -
> _______________________________________________
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint