On 1/3/19 5:02 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Jan 03, 2019 at 12:00:13PM +0200, Panu Matilainen wrote:
> On 1/3/19 11:47 AM, Dridi Boukelmoune wrote:
>>
>>
>> On Thu, Jan 3, 2019, 09:59 Panu Matilainen <pmatilai(a)redhat.com
>> <mailto:pmatilai@redhat.com> wrote:
>>
>> On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
>> >>>>>> "FV" == Fabio Valentini
<decathorpe(a)gmail.com
>> <mailto:decathorpe@gmail.com>> writes:
>> >
>> > FV> - unless those other, main icon theme packages have also added
>> > FV> %transfiletrigger* scriptlets, like I've done for
elementary and
>> > FV> Paper.
>> >
>> > Perhaps it should be mandatory for icon themes to add the
>> necessary file
>> > triggers so that no package will ever need to have a scriptlet which
>> > calls gtk-update-icon-cache.
>> >
>> > In general I think that the distro as a whole should pivot towards
>> > official, guideline-codified scriptlet avoidance, such that adding
>> > appropriate file triggers should be mandatory where it avoids the
>> need
>> > for packages down the dependency chain to have scriptlets. I'm
sure
>> > there are a number of places where this could be done. Having
>> this as a
>> > distro-wide goal would make it easier to get changes like the glibc
>> > ldconfig file triggers implemented (which took years to get the
>> current
>> > incomplete implementation pushed).
>>
>> +1
>>
>> Ultimately the goal should be making the "traditional" scriptlets
>> extinct to the point that using them requires an exception.
>>
>> I've no illusions here, it's going to be a long long road and
require
>> further enhancements to rpm (for example dealing with users and groups)
>> but that's what the long-term overall goal should be.
>>
>>
>> I was wondering about the case of users and groups in scriptlets.
>> Something I would like to investigate next time I dedicate free time to
>> Fedora is conditional and one-shot services with systemd.
>>
>> Maybe some of that complexity could move from the package manager to the
>> service manager. For the use case I have in mind it's definitely the
>> service that wants the user and group, because none of the installed
>> files need them. It's only a runtime requirement for the service.
>
> For the case where the packaged files don't need custom user/groups, you can
> (and probably should) use systemd facilities already: see sysusers.d(5)
>
> That doesn't help with packaged files though, unless split into a separate
> pre-requisite package which is a bit heavy solution for that.
This is a solved problem already.
No it's not.
From systemd.macros:
# This should be used by package installation scripts which require users or
# groups to be present before the files installed by the package are present on
# disk (for example because some files are owned by those users or groups).
#
# Example:
# Source1: %{name}-sysusers.conf
# ...
# %install
# install -D %SOURCE1 %{buildroot}%{_sysusersdir}/%{name}.conf
# %pre
# %sysusers_create_package %{name} %SOURCE1
# %files
# %{_sysusersdir}/%{name}.conf
Also please note that Harald Hoyer and Kay Sievers (in cc) are working on
actually making use of this in Fedora.
Having standard macros for user/group creation is certainly an
improvement over the current situation, but this still requires
scriptlets for a task that should be a declarative item in the spec.
- Panu -