On 1/4/19 12:15 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jan 04, 2019 at 10:56:05AM +0200, Panu Matilainen wrote:
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 <pmati...@redhat.com
<mailto:pmati...@redhat.com> wrote:
On 1/2/19 7:52 PM, Jason L Tibbitts III wrote:
>>>>>> "FV" == Fabio Valentini <decatho...@gmail.com
<mailto:decatho...@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.
It's "solved" in the sense that a fully working solution exists. It
doesn't require a seperate package.
Oh okay you were referring to *that* particularly. In that case, yeah.
The biggest advantage is that the data is declarative in the sysusers
file, the information does not have to be duplicated, and the
scriptlet produces the exact same effect as running sysusers after
installation.
Having this implemented directly in rpm would be an improvement, but
wouldn't change a lot for the packager, because we'd still want the
sysusers file to be installed. I'm not even sure if reimplementing
user creation in rpm would be good. A better solution could be something
like %transfiletriggerpre, where a trigger could be installed for some
file patterns and would run before the rest of the package is installed.
I.e. something like those scriptlets do now, but without having to
define the scriptlet in each package.
Yup, only you need the files unpacked in order to do such a thing, and
at that point it's too late, at least with the way rpm currently works.
Yup. I don't fancy reimplementing user/group management in rpm directly,
I'm thinking more about integrating with existing solutions one way or
the other. Sysusers is a good candidate since, as you point out, it has
a declarative syntax already. The biggest problems with any approach
tend to be with bootstrapping, when installing into an empty chroot
it'll be a good while until any user management tools are present there,
yet the early packages need file ownerships just as much as the latter
ones do. So you'd need to run the tools from outside the chroot and
that'd basically have to happen before the transaction really starts,
which has the slight problem that the filesystem isn't populated. Etc.
- Panu -
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
