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. 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.

Zbyszek
_______________________________________________
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

Reply via email to