Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Ben Cotton]

https://fedoraproject.org/wiki/Features/LimitScriptletUsage

== Summary ==
Remove direct scriptlet calls from "core packages" (those that are
used to build minimal container image). The packages can still affect
changes during installation by placing files in the correct locations
to trigger registered external programs.

== Owner ==
* Name: [[User:james| James Antill]]

== Detailed Description ==

Currently we know how to make an installable OS with packages that
doesn't require the use of scriptlets, indeed rpm-ostree and others
have already done this on a significantly bigger scale. So we plan to
remove direct scriptlets from most (if not all) of the packages in the
main fedora container image for Fedora 31. This means all four of:
%pre/%post/%preun/%postun. After this change it'd be good to have some
kind of temporary exception to be granted before those packages could
add a scriptlet back (post F31 work).

Almost all of the hard work is already done, as rpm can react to files
being dropped in specified places with known actions (Eg. In this way
systemd components can create users or files). There are a few minor
changes needed to packages to move from the old way of doing things
(Eg. calling adduser) to doing the new thing. Note that while a
program will still be run at installation time, those programs will be
few and easily audited (as against the 666 slightly different ways of
adding a user we currently have).

== Benefit to Fedora ==

At the moment all of the packages with scriptlets (and anything
installed with them) are basically opaque programs that happen to also
carry files that are installed, from the point of view of all of the
packaging tools (rpm, ostree, composer, etc.) . After this change the
entire installation of the main container image will be declarative,
and thus. understandable by all of those tools. This should make
things faster, and allow new optimizations and features.

This should also make packagers life easier in the long term, as
packaging becomes less unique.

== Scope ==

Proposal owners:

* James Antill
* 1 needs to get combine.d into the distribution, and then /etc/shells
can use that.
* 2 minor wrangling of package owners to tweak specfiles.

* Other developers:

* Policies and guidelines: We should work toward only allowing new
scriptlets to appear with policy exceptions, in any of the fixed
packages. This needs to be done somewhat carefully, and post F31.

== How To Test ==
All of the following should provide no output on a standard container:

 * rpm -a --qf '%{preinprog}'
 * rpm -a --qf '%{preunprog}'
 * rpm -a --qf '%{postinprog}'
 * rpm -a --qf '%{postunprog}'
 * rpm -a --qf '%{pretransprog}'
 * rpm -a --qf '%{posttransprog}'

== User Experience ==
There should be no significant difference to users, initially,
although package installation should be faster.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
Until higher level packaging/installation tooling starts to depend on
the scriptlets not being present it is always possible to just let
those packages which still have scriptlets continue, if it's required.

* Contingency mechanism: Just ship packages with scriptlets, as we
always have done.
* Contingency deadline: N/A
* Blocks release? No

== Documentation ==
N/A (not a System Wide Change)

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Robbie Harwood]

Ben Cotton <bcotton(a)redhat.com&gt; writes:

>  == Detailed Description ==
>
>  Currently we know how to make an installable OS with packages that
>  doesn't require the use of scriptlets, indeed rpm-ostree and others
>  have already done this on a significantly bigger scale. So we plan to
>  remove direct scriptlets from most (if not all) of the packages in the
>  main fedora container image for Fedora 31. This means all four of:
>  %pre/%post/%preun/%postun. After this change it'd be good to have some
>  kind of temporary exception to be granted before those packages could
>  add a scriptlet back (post F31 work). 
Do I understand correctly that triggers aren't affected here?

>  Almost all of the hard work is already done, as rpm can react to
> files
>  being dropped in specified places with known actions (Eg. In this way
>  systemd components can create users or files). There are a few minor
>  changes needed to packages to move from the old way of doing things
>  (Eg. calling adduser) to doing the new thing. Note that while a
>  program will still be run at installation time, those programs will be
>  few and easily audited (as against the 666 slightly different ways of
>  adding a user we currently have). 
Is there a document describing common things that are done with
scriptlets and the "proper", non-scriptlet way to do them?  (If not,
could one be made?)

>  == Scope ==
>
>  Proposal owners:
>
>  * James Antill
>  * 1 needs to get combine.d into the distribution, and then /etc/shells
>  can use that.
>  * 2 minor wrangling of package owners to tweak specfiles. 
Do I understand correctly that you plan to send PRs to all packages in
question?

>  * Other developers:
>
>  * Policies and guidelines: We should work toward only allowing new
>  scriptlets to appear with policy exceptions, in any of the fixed
>  packages. This needs to be done somewhat carefully, and post F31. 
Would it be possible to write the policy first, rather than trying to
get maintainers to conform to an unknown standard?

Thanks,
--Robbie

[James Antill]

On Mon, 2019-07-01 at 17:03 -0400, Robbie Harwood wrote:
>  Ben Cotton <bcotton(a)redhat.com&gt; writes:
>  
>  > == Detailed Description ==
>  > 
>  > Currently we know how to make an installable OS with packages that
>  > doesn't require the use of scriptlets, indeed rpm-ostree and others
>  > have already done this on a significantly bigger scale. So we plan
>  > to
>  > remove direct scriptlets from most (if not all) of the packages in
>  > the
>  > main fedora container image for Fedora 31. This means all four of:
>  > %pre/%post/%preun/%postun. After this change it'd be good to have
>  > some
>  > kind of temporary exception to be granted before those packages
>  > could
>  > add a scriptlet back (post F31 work).
>  
>  Do I understand correctly that triggers aren't affected here? 
 Yes.

>  > Almost all of the hard work is already done, as rpm can react
> to
>  > files
>  > being dropped in specified places with known actions (Eg. In this
>  > way
>  > systemd components can create users or files). There are a few
>  > minor
>  > changes needed to packages to move from the old way of doing things
>  > (Eg. calling adduser) to doing the new thing. Note that while a
>  > program will still be run at installation time, those programs will
>  > be
>  > few and easily audited (as against the 666 slightly different ways
>  > of
>  > adding a user we currently have).
>  
>  Is there a document describing common things that are done with
>  scriptlets and the "proper", non-scriptlet way to do them?  (If not,
>  could one be made?) 
 I don't believe there is a single document atm. ... I could look at
putting one somewhere, although it's a bit like lumping random things
together because we happen to be doing them at the same time.

>  > == Scope ==
>  > 
>  > Proposal owners:
>  > 
>  > * James Antill
>  > * 1 needs to get combine.d into the distribution, and then
>  > /etc/shells
>  > can use that.
>  > * 2 minor wrangling of package owners to tweak specfiles.
>  
>  Do I understand correctly that you plan to send PRs to all packages
>  in question? 
 Yes.

>  > * Other developers:
>  > 
>  > * Policies and guidelines: We should work toward only allowing new
>  > scriptlets to appear with policy exceptions, in any of the fixed
>  > packages. This needs to be done somewhat carefully, and post F31.
>  
>  Would it be possible to write the policy first, rather than trying to
>  get maintainers to conform to an unknown standard? 
 The policy here is talking about after it's done, so that things don't
slide back. Kind of like the "no new sysv-init scripts" came after the
conversion to systemd unit files was accpeted/done.

[Miroslav Suchý]

Dne 01. 07. 19 v 23:18 James Antill napsal(a):
>   I don't believe there is a single document atm. ... I could look
> at
>  putting one somewhere, although it's a bit like lumping random things
>  together because we happen to be doing them at the same time. 
Even list of links pointing to all those PR would be nice. I would *love* to learn how to
do that so I can do that for
my packages as well.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

[Tomas Mraz]

On Mon, 2019-07-01 at 17:18 -0400, James Antill wrote:
>  On Mon, 2019-07-01 at 17:03 -0400, Robbie Harwood wrote:
>  > Ben Cotton <bcotton(a)redhat.com&gt; writes:
>  > 
>  > > == Detailed Description ==
>  > > 
>  > > Currently we know how to make an installable OS with packages
>  > > that
>  > > doesn't require the use of scriptlets, indeed rpm-ostree and
>  > > others
>  > > have already done this on a significantly bigger scale. So we
>  > > plan
>  > > to
>  > > remove direct scriptlets from most (if not all) of the packages
>  > > in
>  > > the
>  > > main fedora container image for Fedora 31. This means all four
>  > > of:
>  > > %pre/%post/%preun/%postun. After this change it'd be good to have
>  > > some
>  > > kind of temporary exception to be granted before those packages
>  > > could
>  > > add a scriptlet back (post F31 work).
>  > 
>  > Do I understand correctly that triggers aren't affected here?
>  
>   Yes.
>  
>  > > Almost all of the hard work is already done, as rpm can react to
>  > > files
>  > > being dropped in specified places with known actions (Eg. In this
>  > > way
>  > > systemd components can create users or files). There are a few
>  > > minor
>  > > changes needed to packages to move from the old way of doing
>  > > things
>  > > (Eg. calling adduser) to doing the new thing. Note that while a
>  > > program will still be run at installation time, those programs
>  > > will
>  > > be
>  > > few and easily audited (as against the 666 slightly different
>  > > ways
>  > > of
>  > > adding a user we currently have).
>  > 
>  > Is there a document describing common things that are done with
>  > scriptlets and the "proper", non-scriptlet way to do them?  (If
>  > not,
>  > could one be made?)
>  
>   I don't believe there is a single document atm. ... I could look at
>  putting one somewhere, although it's a bit like lumping random things
>  together because we happen to be doing them at the same time. 
OK, let's talk about concrete package: crypto-policies needs to run
update-crypto-policies --no-check >/dev/null

It currently does it in %post.

It could do it in %posttrans - that would be one option. What are the
other options?

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

[Adam Williamson]

On Thu, 2019-07-04 at 11:38 +0200, Tomas Mraz wrote:
>  
>  OK, let's talk about concrete package: crypto-policies needs to run
>  update-crypto-policies --no-check >/dev/null
>  
>  It currently does it in %post.
>  
>  It could do it in %posttrans - that would be one option. 
Presumably only if no other package being installed needed correct
crypto policies for its scriptlets?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Tomas Mraz]

On Thu, 2019-07-04 at 09:03 -0700, Adam Williamson wrote:
>  On Thu, 2019-07-04 at 11:38 +0200, Tomas Mraz wrote:
>  > OK, let's talk about concrete package: crypto-policies needs to run
>  > update-crypto-policies --no-check >/dev/null
>  > 
>  > It currently does it in %post.
>  > 
>  > It could do it in %posttrans - that would be one option.
>  
>  Presumably only if no other package being installed needed correct
>  crypto policies for its scriptlets? 
Well, there would be _some_ configuration present from the crypto-
policy package install at least. And on updates there will be the
previous version. So this would be needed only in case the policy was
for some reason broken in the previous version and we are doing an
update and want to fix the breakage for the other packages scriptlets.

I think this is a fairly obscure scenario that we can ignore unless
there is any other non-obscure way how to avoid it.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

[Vít Ondruch]

Wonderful. Is there some tracker covering the issues/packages? I was
recently looking into filesystem:

https://bugzilla.redhat.com/show_bug.cgi?id=1306489#c7


Vít


Dne 01. 07. 19 v 22:26 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Features/LimitScriptletUsage
>
> == Summary ==
> Remove direct scriptlet calls from "core packages" (those that are
> used to build minimal container image). The packages can still affect
> changes during installation by placing files in the correct locations
> to trigger registered external programs.
>
> == Owner ==
> * Name: [[User:james| James Antill]]
>
> == Detailed Description ==
>
> Currently we know how to make an installable OS with packages that
> doesn't require the use of scriptlets, indeed rpm-ostree and others
> have already done this on a significantly bigger scale. So we plan to
> remove direct scriptlets from most (if not all) of the packages in the
> main fedora container image for Fedora 31. This means all four of:
> %pre/%post/%preun/%postun. After this change it'd be good to have some
> kind of temporary exception to be granted before those packages could
> add a scriptlet back (post F31 work).
>
> Almost all of the hard work is already done, as rpm can react to files
> being dropped in specified places with known actions (Eg. In this way
> systemd components can create users or files). There are a few minor
> changes needed to packages to move from the old way of doing things
> (Eg. calling adduser) to doing the new thing. Note that while a
> program will still be run at installation time, those programs will be
> few and easily audited (as against the 666 slightly different ways of
> adding a user we currently have).
>
> == Benefit to Fedora ==
>
> At the moment all of the packages with scriptlets (and anything
> installed with them) are basically opaque programs that happen to also
> carry files that are installed, from the point of view of all of the
> packaging tools (rpm, ostree, composer, etc.) . After this change the
> entire installation of the main container image will be declarative,
> and thus. understandable by all of those tools. This should make
> things faster, and allow new optimizations and features.
>
> This should also make packagers life easier in the long term, as
> packaging becomes less unique.
>
> == Scope ==
>
> Proposal owners:
>
> * James Antill
> * 1 needs to get combine.d into the distribution, and then /etc/shells
> can use that.
> * 2 minor wrangling of package owners to tweak specfiles.
>
> * Other developers:
>
> * Policies and guidelines: We should work toward only allowing new
> scriptlets to appear with policy exceptions, in any of the fixed
> packages. This needs to be done somewhat carefully, and post F31.
>
> == How To Test ==
> All of the following should provide no output on a standard container:
>
>  * rpm -a --qf '%{preinprog}'
>  * rpm -a --qf '%{preunprog}'
>  * rpm -a --qf '%{postinprog}'
>  * rpm -a --qf '%{postunprog}'
>  * rpm -a --qf '%{pretransprog}'
>  * rpm -a --qf '%{posttransprog}'
>
> == User Experience ==
> There should be no significant difference to users, initially,
> although package installation should be faster.
>
> == Dependencies ==
> N/A (not a System Wide Change)
>
> == Contingency Plan ==
> Until higher level packaging/installation tooling starts to depend on
> the scriptlets not being present it is always possible to just let
> those packages which still have scriptlets continue, if it's required.
>
> * Contingency mechanism: Just ship packages with scriptlets, as we
> always have done.
> * Contingency deadline: N/A
> * Blocks release? No
>
> == Documentation ==
> N/A (not a System Wide Change)
>

[Richard W.M. Jones]

On Mon, Jul 01, 2019 at 04:26:07PM -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Features/LimitScriptletUsage
>  
>  == Summary ==
>  Remove direct scriptlet calls from "core packages" (those that are
>  used to build minimal container image). The packages can still affect
>  changes during installation by placing files in the correct locations
>  to trigger registered external programs. 
Really excellent news.  I've been calling for this for a very long
time:

https://lists.fedoraproject.org/archives/list/[e-mail].o...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 01, 2019 at 04:26:07PM -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Features/LimitScriptletUsage
>  
>  == Summary ==
>  Remove direct scriptlet calls from "core packages" (those that are
>  used to build minimal container image). The packages can still affect
>  changes during installation by placing files in the correct locations
>  to trigger registered external programs.
>  
>  == Owner ==
>  * Name: [[User:james| James Antill]]
>  
>  == Detailed Description ==
>  
>  Currently we know how to make an installable OS with packages that
>  doesn't require the use of scriptlets, indeed rpm-ostree and others
>  have already done this on a significantly bigger scale. So we plan to
>  remove direct scriptlets from most (if not all) of the packages in the
>  main fedora container image for Fedora 31. This means all four of:
>  %pre/%post/%preun/%postun. After this change it'd be good to have some
>  kind of temporary exception to be granted before those packages could
>  add a scriptlet back (post F31 work).
>  
>  Almost all of the hard work is already done, as rpm can react to files
>  being dropped in specified places with known actions (Eg. In this way
>  systemd components can create users or files). There are a few minor
>  changes needed to packages to move from the old way of doing things
>  (Eg. calling adduser) to doing the new thing. Note that while a
>  program will still be run at installation time, those programs will be
>  few and easily audited (as against the 666 slightly different ways of
>  adding a user we currently have). 
I love the goal, but this document says very little about the means to
achieve that goal. I would like to see specific solutions described
for each class of scriptlets that is present, including approximate
numbers of packages that are affected. As often, the devil is in the
details, and there indeed are classes of scriptlets which have been
successfully made obsolete and we now only need to get rid of the usage
usage in spec files, but then there are other classes of scriptlets
which might be very hard to replace.

As as example: how do you want to get rid of %systemd_postun_with_restart?

Also, this certainly is not a "self contained" change. Please upgrade
it to "system wide".

Zbyszek

PS.
>  All of the following should provide no output on a standard
> container:
>  
>   * rpm -a --qf '%{preinprog}'
>   * rpm -a --qf '%{preunprog}'
>   * rpm -a --qf '%{postinprog}'
>   * rpm -a --qf '%{postunprog}'
>   * rpm -a --qf '%{pretransprog}'
>   * rpm -a --qf '%{posttransprog}' 
This needs "-q" and "|
grep -v '(none)'". I changed the wiki page.

Zbyszek

[James Antill]

On Tue, 2019-07-02 at 10:22 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  
>  I love the goal, but this document says very little about the means
>  to achieve that goal. I would like to see specific solutions
>  described for each class of scriptlets that is present, including
>  approximate numbers of packages that are affected. As often, the
>  devil is in the details, and there indeed are classes of scriptlets
>  which have been successfully made obsolete and we now only need to
>  get rid of the usage usage in spec files, but then there are other
>  classes of scriptlets which might be very hard to replace. 
 Yes, we've had a spreadsheet for a bit with that data (raw data
generated by[1]), I'll try to get that into html/wiki this week.
 For a significant portion of the work the plan is:

1. ldconfig => delete them as not needed
2. adduser/group/etc. => sysusers files
3. touch/mv/cp/etc. => systemd-tmpfiles

...there have been ideas for some of the exceptional cases, but if we
don't it all of them for F31 we'll still be in a better place for F32.


[1] https://github.com/james-antill/scriptlets-monitor

>  Also, this certainly is not a "self contained" change.
> Please upgrade
>  it to "system wide". 
 Although we'd change multiple packages, we don't need to co-ordinate
much between packages and there won't be any big flag day like event
which is why I chose self contained.

[Florian Weimer]

* James Antill:

>   Yes, we've had a spreadsheet for a bit with that data (raw data
>  generated by[1]), I'll try to get that into html/wiki this week.
>   For a significant portion of the work the plan is:
>
>  1. ldconfig => delete them as not needed
>  2. adduser/group/etc. => sysusers files
>  3. touch/mv/cp/etc. => systemd-tmpfiles
>
>  ...there have been ideas for some of the exceptional cases, but if we
>  don't it all of them for F31 we'll still be in a better place for F32. 
Do you have a way to remove files from search paths before remaining
scriptlets (from non-core packages, for example) run?  RPM deletes
removed files very late in the transaction, and if they are still on
search paths, this might cause problems.

So far, we have used %post scriptlets to delete these files immediately.

Thanks,
Florian

[James Antill]

On Wed, 2019-07-10 at 10:36 +0200, Florian Weimer wrote:
>  
>  Do you have a way to remove files from search paths before remaining
>  scriptlets (from non-core packages, for example) run?  RPM deletes
>  removed files very late in the transaction, and if they are still on
>  search paths, this might cause problems. 
 No ... the quick answer to a lot of similar questions is if it's not
in the current set of package scriptlets from the default image or
@server-product-environment then AFAIK nobody's thought about how to do
it another way.

>  So far, we have used %post scriptlets to delete these files
>  immediately. 
 It will still be technically possible to use scriptlets, if we need to
workaround upgrade problems in the future, however I'd assume the long
term goal would be that enough packages wouldn't that we wouldn't need
to do workarounds like the above.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 10, 2019 at 03:19:43AM -0400, James Antill wrote:
>  On Tue, 2019-07-02 at 10:22 +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
>  > 
>  > I love the goal, but this document says very little about the means
>  > to achieve that goal. I would like to see specific solutions
>  > described for each class of scriptlets that is present, including
>  > approximate numbers of packages that are affected. As often, the
>  > devil is in the details, and there indeed are classes of scriptlets
>  > which have been successfully made obsolete and we now only need to
>  > get rid of the usage usage in spec files, but then there are other
>  > classes of scriptlets which might be very hard to replace.
>  
>   Yes, we've had a spreadsheet for a bit with that data (raw data
>  generated by[1]), I'll try to get that into html/wiki this week.
>   For a significant portion of the work the plan is:
>  
>  1. ldconfig => delete them as not needed 
Right. It's insane how many of
those we still have. On my F30 box,
"rpm -q -a --scripts |rg -c ldconfig" says 107! Getting rid of those
would certainly be nice.

>  2. adduser/group/etc. => sysusers files
>  3. touch/mv/cp/etc. => systemd-tmpfiles 
tmpfiles doesn't support moving
stuff. It might be possible to make
do with a copy and remove operation, but that doesn't seem nice.

Otherwise, tmpfiles and sysusers are there, and should work. But
sysusers hasn't such thaaat much exposure yet. But if there are any
shortcomings, we should be able to fix them.

>  ...there have been ideas for some of the exceptional cases, but if
> we
>  don't it all of them for F31 we'll still be in a better place for F32. 
Agreed. I'm not yet convinced we can get rid of all scriptlets in a way
that would require workarounds that are more painful than the original
scriptlets, but I'm sure we can should down 90% of scriptlets.

Zbyszek

[Neal Gompa]

On Thu, Jul 11, 2019 at 4:26 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Wed, Jul 10, 2019 at 03:19:43AM -0400, James Antill wrote:
>  > On Tue, 2019-07-02 at 10:22 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  > >
>  > > I love the goal, but this document says very little about the means
>  > > to achieve that goal. I would like to see specific solutions
>  > > described for each class of scriptlets that is present, including
>  > > approximate numbers of packages that are affected. As often, the
>  > > devil is in the details, and there indeed are classes of scriptlets
>  > > which have been successfully made obsolete and we now only need to
>  > > get rid of the usage usage in spec files, but then there are other
>  > > classes of scriptlets which might be very hard to replace.
>  >
>  >  Yes, we've had a spreadsheet for a bit with that data (raw data
>  > generated by[1]), I'll try to get that into html/wiki this week.
>  >  For a significant portion of the work the plan is:
>  >
>  > 1. ldconfig => delete them as not needed
>  Right. It's insane how many of those we still have. On my F30 box,
>  "rpm -q -a --scripts |rg -c ldconfig" says 107! Getting rid of those
>  would certainly be nice.
>
>  > 2. adduser/group/etc. => sysusers files
>  > 3. touch/mv/cp/etc. => systemd-tmpfiles
>  tmpfiles doesn't support moving stuff. It might be possible to make
>  do with a copy and remove operation, but that doesn't seem nice.
>
>  Otherwise, tmpfiles and sysusers are there, and should work. But
>  sysusers hasn't such thaaat much exposure yet. But if there are any
>  shortcomings, we should be able to fix them.
>
>  > ...there have been ideas for some of the exceptional cases, but if we
>  > don't it all of them for F31 we'll still be in a better place for F32.
>
>  Agreed. I'm not yet convinced we can get rid of all scriptlets in a way
>  that would require workarounds that are more painful than the original
>  scriptlets, but I'm sure we can should down 90% of scriptlets.
>  
I disagree about the user/group creation, at least the way it's being
planned in here.

The way openSUSE solved this problem probably makes sense for dealing
with issues like needing the users+groups to exist before package is
being installed:

1. sysusers are in their own (sub)packages, dep generators generate user()
and group() Provides
2. main package can require those user() and group() names, forcing
the sysusers to be installed first
3. Transaction ordering deals with the rest of the problem :)




--
真実はいつも一つ！/ Always, there's only one truth!

[Dridi Boukelmoune]

>  I disagree about the user/group creation, at least the way it's
> being
>  planned in here.
>
>  The way openSUSE solved this problem probably makes sense for dealing
>  with issues like needing the users+groups to exist before package is
>  being installed:
>
>  1. sysusers are in their own (sub)packages, dep generators generate user()
>  and group() Provides
>  2. main package can require those user() and group() names, forcing
>  the sysusers to be installed first
>  3. Transaction ordering deals with the rest of the problem :) 
Sounds like something similar debuginfo packages where we don't have
to do anything besides compiling with debug symbols, except that here
we'd need to either install the sysusers file if it comes from upstream or
create one, and I assume everything else would be handled automatically?

I would be on board for such a change, as I would like to do that for
the varnish package (ideally on el7 too if that can be ported over
there). I have strongly considered doing that manually since this
needs to be done beforehand, and in my specific case (wearing my
upstream hat) we would be fine with the user short-circuiting the
sysusers file prior to installation as the users/group we recommend
are optional and /usr/*bin/varnish* tools can also work with other
arbitrary credentials of the sysadmin's discretion to drop privileges.

(Please keep the latter in mind for other packages, they may break if
someone drops a different sysusers file in /etc, but ten they probably
asked for it.)




Dridi

[Miroslav Suchý]

Dne 10. 07. 19 v 9:19 James Antill napsal(a):
>  2. adduser/group/etc. => sysusers files 
For anyone willing to do this in advance on his/her package - this is how you can do
that:

https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...

Here is relevant FPC ticket:
  https://pagure.io/packaging-committee/issue/442

Just for the record - this does not make things to run faster. You still have to have %pre
scriptlets. It is likely even
slower as you are running %posttranstrigger as well. The benefit is here only that we move
toward declarative specification.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

[Neal Gompa]

On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
>  Dne 10. 07. 19 v 9:19 James Antill napsal(a):
>  > 2. adduser/group/etc. => sysusers files
>
>  For anyone willing to do this in advance on his/her package - this is how you can do
> that:
>
>
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
>
>  Here is relevant FPC ticket:
>    https://pagure.io/packaging-committee/issue/442
>
>  Just for the record - this does not make things to run faster. You still have to have
> %pre scriptlets. It is likely even
>  slower as you are running %posttranstrigger as well. The benefit is here only that we
> move toward declarative specification.
>  
That’s also going to fail, because the %pre script executes before the
file exists. That’s why these guidelines are broken, and why I
suggested we deal with sysusers differently.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
>  On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý
> <msuchy(a)redhat.com&gt; wrote:
>  >
>  > Dne 10. 07. 19 v 9:19 James Antill napsal(a):
>  > > 2. adduser/group/etc. => sysusers files
>  >
>  > For anyone willing to do this in advance on his/her package - this is how you can do
> that:
>  >
>  >
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
>  >
>  > Here is relevant FPC ticket:
>  >   https://pagure.io/packaging-committee/issue/442
>  >
>  > Just for the record - this does not make things to run faster. You still have to
> have %pre scriptlets. It is likely even
>  > slower as you are running %posttranstrigger as well. The benefit is here only that
> we move toward declarative specification.
>  >
>  
>  That’s also going to fail, because the %pre script executes before the
>  file exists. That’s why these guidelines are broken, and why I
>  suggested we deal with sysusers differently. 
Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
%sysusers_create is "deprecated. Use %sysusers_create_package instead".

Zbyszek

[Vít Ondruch]

Dne 15. 07. 19 v 17:03 Zbigniew Jędrzejewski-Szmek napsal(a):
>  On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
> > On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
> >> Dne 10. 07. 19 v 9:19 James Antill napsal(a):
> >>> 2. adduser/group/etc. => sysusers files
> >> For anyone willing to do this in advance on his/her package - this is how you can
> do that:
> >>
> >>
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
> >>
> >> Here is relevant FPC ticket:
> >>   https://pagure.io/packaging-committee/issue/442
> >>
> >> Just for the record - this does not make things to run faster. You still have to
> have %pre scriptlets. It is likely even
> >> slower as you are running %posttranstrigger as well. The benefit is here only
> that we move toward declarative specification.
> >>
> > That’s also going to fail, because the %pre script executes before the
> > file exists. That’s why these guidelines are broken, and why I
> > suggested we deal with sysusers differently.
>  Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
>  %sysusers_create is "deprecated. Use %sysusers_create_package instead". 

I just wonder what is the point of:

https://github.com/systemd/systemd/blob/b0ca726/src/core/macros.systemd.i...

Why should the file be stored on the FS, when it is expanded during
build time (if I understand the scriptlet correctly).


Vít


>
> Zbyszek
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Jason L Tibbitts III]

> >>>> "VO" == Vít Ondruch
> <vondruch(a)redhat.com&gt; writes: 
VO> I just wonder what is the point of:

VO> https://github.com/systemd/systemd/blob/b0ca726/src/core/macros.systemd.i...

I guess it just saves packagers from having to call systemd-sysusers
properly.  You include the configuration file in the source package and
that macro basically just expands it into the spec.

VO> Why should the file be stored on the FS, when it is expanded during
VO> build time (if I understand the scriptlet correctly).

Well you could just bypass the macro and call systemd-sysusers
yourself with the raw data as part of the command.  I don't see anything
that requires the file to exist in the filesystem at runtime.

Personally I do think the subpackage method has merit, but hiding it
behind macros (if we want that) would probably be complex.  But
debuginfo/debugsource packages are done that way so it should be
possible.

 - J<

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 15, 2019 at 01:24:06PM -0500, Jason L Tibbitts III wrote:
>  >>>>> "VO" == Vít Ondruch
> <vondruch(a)redhat.com&gt; writes:
>  
>  VO> I just wonder what is the point of:
>  
>  VO> https://github.com/systemd/systemd/blob/b0ca726/src/core/macros.systemd.i...
>  
>  You include the configuration file in the source package and
>  that macro basically just expands it into the spec. 
The general idea is that result of running systemd-sysusers should be
idempotent. If systemd-sysusers is called from a scriptlet or not,
and then is later called from the running system, no matter how many
times, the same configuration is used and the result "on disk" is the
same. To achieve this, the snippet is both installed on disk (a), and
embedded into the scriptlet (b).

There is a subtlety: the administrator is allowed to override sysusers
configuration (the same as almost any other part of systemd configuration).
Such overrides are obviously honoured when systemd-sysusers is run
normally, but also when it is run from a scriptlet. To this end, the
scriptlet macro tells systemd-sysuers to insert config (b) in the same
priority order where (a) would be inserted.

Another general systemd principle is that it should be possible to
wipe /etc and /var and reboot, and things should "just work" as far as
possible. systemd-sysusers will recreate users on reboot, so by installing
the file on disk the package supports this mode of operation for that
part.

>  I guess it just saves packagers from having to call systemd-sysusers
>  properly. 
Not exactly ;)

>  VO> Why should the file be stored on the FS, when it is expanded
> during
>  VO> build time (if I understand the scriptlet correctly).
>  
>  Well you could just bypass the macro and call systemd-sysusers
>  yourself with the raw data as part of the command.  I don't see anything
>  that requires the file to exist in the filesystem at runtime. 
We install the file in the filesystem for the reasons listed above,
but also to serve as documentation. It's a tiny file but it tells
the administrator where the user came from.
 
>  Personally I do think the subpackage method has merit, but hiding it
>  behind macros (if we want that) would probably be complex.  But
>  debuginfo/debugsource packages are done that way so it should be
>  possible. 
Yep, it's definitely worth exploring.

Zbyszek

[Neal Gompa]

On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
>  > On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
>  > >
>  > > Dne 10. 07. 19 v 9:19 James Antill napsal(a):
>  > > > 2. adduser/group/etc. => sysusers files
>  > >
>  > > For anyone willing to do this in advance on his/her package - this is how you
> can do that:
>  > >
>  > >
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
>  > >
>  > > Here is relevant FPC ticket:
>  > >   https://pagure.io/packaging-committee/issue/442
>  > >
>  > > Just for the record - this does not make things to run faster. You still have
> to have %pre scriptlets. It is likely even
>  > > slower as you are running %posttranstrigger as well. The benefit is here only
> that we move toward declarative specification.
>  > >
>  >
>  > That’s also going to fail, because the %pre script executes before the
>  > file exists. That’s why these guidelines are broken, and why I
>  > suggested we deal with sysusers differently.
>
>  Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
>  %sysusers_create is "deprecated. Use %sysusers_create_package instead".
>  
It’d be better to subpackage it and have a file trigger that runs for
each package that contains those files and creates the sysusers. That
ensures ordering, existence, and makes it reliable. Subpackages will
also allow other packages to be able to depend on those if needed
without the software (e.g. apache user being used by both apache httpd
and nginx).



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Panu Matilainen]

On 7/15/19 6:57 PM, Neal Gompa wrote:
>  On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; wrote:
> >
> > On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
> >> On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
> >>>
> >>> Dne 10. 07. 19 v 9:19 James Antill napsal(a):
> >>>> 2. adduser/group/etc. => sysusers files
> >>>
> >>> For anyone willing to do this in advance on his/her package - this is how you
> can do that:
> >>>
> >>>
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
> >>>
> >>> Here is relevant FPC ticket:
> >>>    https://pagure.io/packaging-committee/issue/442
> >>>
> >>> Just for the record - this does not make things to run faster. You still have
> to have %pre scriptlets. It is likely even
> >>> slower as you are running %posttranstrigger as well. The benefit is here only
> that we move toward declarative specification.
> >>>
> >>
> >> That’s also going to fail, because the %pre script executes before the
> >> file exists. That’s why these guidelines are broken, and why I
> >> suggested we deal with sysusers differently.
> >
> > Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
> > %sysusers_create is "deprecated. Use %sysusers_create_package instead".
> >
>  
>  It’d be better to subpackage it and have a file trigger that runs for
>  each package that contains those files and creates the sysusers. That
>  ensures ordering, existence, and makes it reliable. Subpackages will
>  also allow other packages to be able to depend on those if needed
>  without the software (e.g. apache user being used by both apache httpd
>  and nginx). 
I was about to say sub-packages seem a bit heavy solution to user 
creation but instead I'm going to say that thinking about it a bit, it 
is a pretty powerful solution (user/group -dependencies being a nice 
example) and one that actually works by leveraging widely deployed rpm 
mechanisms.

And since that's used by OpenSUSE then basically we just need to adopt a 
working solution, and we'd be increasing unity in the packaging world as 
an extra bonus.

So a big +1 for sysusers in sub-packages + file trigger to handle 
running systemd-sysusers. It solves more problems than the current 
sysusers-proposal and in a far more elegant way at that.

	- Panu -

[Neal Gompa]

On Tue, Jul 30, 2019 at 5:47 AM Panu Matilainen <pmatilai(a)redhat.com&gt; wrote:
>  On 7/15/19 6:57 PM, Neal Gompa wrote:
>  > On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
>  > <zbyszek(a)in.waw.pl&gt; wrote:
>  >>
>  >> On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
>  >>> On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý <msuchy(a)redhat.com&gt;
> wrote:
>  >>>>
>  >>>> Dne 10. 07. 19 v 9:19 James Antill napsal(a):
>  >>>>> 2. adduser/group/etc. => sysusers files
>  >>>>
>  >>>> For anyone willing to do this in advance on his/her package - this is
> how you can do that:
>  >>>>
>  >>>>
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
>  >>>>
>  >>>> Here is relevant FPC ticket:
>  >>>>    https://pagure.io/packaging-committee/issue/442
>  >>>>
>  >>>> Just for the record - this does not make things to run faster. You still
> have to have %pre scriptlets. It is likely even
>  >>>> slower as you are running %posttranstrigger as well. The benefit is here
> only that we move toward declarative specification.
>  >>>>
>  >>>
>  >>> That’s also going to fail, because the %pre script executes before the
>  >>> file exists. That’s why these guidelines are broken, and why I
>  >>> suggested we deal with sysusers differently.
>  >>
>  >> Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
>  >> %sysusers_create is "deprecated. Use %sysusers_create_package
> instead".
>  >>
>  >
>  > It’d be better to subpackage it and have a file trigger that runs for
>  > each package that contains those files and creates the sysusers. That
>  > ensures ordering, existence, and makes it reliable. Subpackages will
>  > also allow other packages to be able to depend on those if needed
>  > without the software (e.g. apache user being used by both apache httpd
>  > and nginx).
>
>  I was about to say sub-packages seem a bit heavy solution to user
>  creation but instead I'm going to say that thinking about it a bit, it
>  is a pretty powerful solution (user/group -dependencies being a nice
>  example) and one that actually works by leveraging widely deployed rpm
>  mechanisms.
>
>  And since that's used by OpenSUSE then basically we just need to adopt a
>  working solution, and we'd be increasing unity in the packaging world as
>  an extra bonus.
>
>  So a big +1 for sysusers in sub-packages + file trigger to handle
>  running systemd-sysusers. It solves more problems than the current
>  sysusers-proposal and in a far more elegant way at that.
>  
The ideal would be that RPM would have native functionality for
managing these things, but this is the next best thing, in my view.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Jason L Tibbitts III]

> >>>> "PM" == Panu Matilainen
> <pmatilai(a)redhat.com&gt; writes: 
PM> So a big +1 for sysusers in sub-packages + file trigger to handle
PM> running systemd-sysusers. It solves more problems than the current
PM> sysusers-proposal and in a far more elegant way at that.

It's great that you agree.  That leaves all of the details.  What's the
simplest way to accomplish this in a way that's easy for packagers to
use?  Is there any way for RPM to do this internally?

I would really like to avoid this becoming a bunch of extra boilerplate
in the relevant packages, or rather, for this conversion to result in a
net reduction of boilerplate.  Can the subpackage generation be
reasonably hidden behind macros?  Or is it possible to use a mechanism
similar to the way debuginfo packages are generated to automatically
define the subpackages when necessary?

A related question is whether there are any cases where multiple
packages (from different SRPMs) which don't depend on each other but all
depend on the same user being created.  Our current methods handle this
well enough (all of the packages just create the user) but that probably
won't work in any scheme using sysusers.  The way to handle that seems
relatively obvious (just have a separate SRPM that creates the user upon
which the other packages can depend) but I don't know if it's a case
that would need to be documented.

 - J<

[Panu Matilainen]

On 7/30/19 6:10 PM, Jason L Tibbitts III wrote:
> >>>>> "PM" == Panu Matilainen
> <pmatilai(a)redhat.com&gt; writes:
>  
>  PM> So a big +1 for sysusers in sub-packages + file trigger to handle
>  PM> running systemd-sysusers. It solves more problems than the current
>  PM> sysusers-proposal and in a far more elegant way at that.
>  
>  It's great that you agree.  That leaves all of the details.  What's the
>  simplest way to accomplish this in a way that's easy for packagers to
>  use?  Is there any way for RPM to do this internally?
>  
>  I would really like to avoid this becoming a bunch of extra boilerplate
>  in the relevant packages, or rather, for this conversion to result in a
>  net reduction of boilerplate.  Can the subpackage generation be
>  reasonably hidden behind macros?  Or is it possible to use a mechanism
>  similar to the way debuginfo packages are generated to automatically
>  define the subpackages when necessary? 
No idea. I'd suggest taking a look at what OpenSUSE has done in this 
area. I haven't looked at the details at all, that somebody is using 
sysusers this way I only learned from this thread last week.

>  
>  A related question is whether there are any cases where multiple
>  packages (from different SRPMs) which don't depend on each other but all
>  depend on the same user being created.  Our current methods handle this
>  well enough (all of the packages just create the user) but that probably
>  won't work in any scheme using sysusers.  The way to handle that seems
>  relatively obvious (just have a separate SRPM that creates the user upon
>  which the other packages can depend) but I don't know if it's a case
>  that would need to be documented. 
A separate source package is one way, but it could be just as well 
created by a sub-package by one of those multiple packages. Or maybe 
such a thing would belong in setup, or a sysuser sub-package from it. 
Again, I'd just look at what others have done before reinventing anything.

	- Panu -

>  
>    - J<
>

[Neal Gompa]

On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
>  > On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
>  > >
>  > > Dne 10. 07. 19 v 9:19 James Antill napsal(a):
>  > > > 2. adduser/group/etc. => sysusers files
>  > >
>  > > For anyone willing to do this in advance on his/her package - this is how you
> can do that:
>  > >
>  > >
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
>  > >
>  > > Here is relevant FPC ticket:
>  > >   https://pagure.io/packaging-committee/issue/442
>  > >
>  > > Just for the record - this does not make things to run faster. You still have
> to have %pre scriptlets. It is likely even
>  > > slower as you are running %posttranstrigger as well. The benefit is here only
> that we move toward declarative specification.
>  > >
>  >
>  > That’s also going to fail, because the %pre script executes before the
>  > file exists. That’s why these guidelines are broken, and why I
>  > suggested we deal with sysusers differently.
>
>  Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
>  %sysusers_create is "deprecated. Use %sysusers_create_package instead".
>  
And to note, even this change doesn't work:
https://github.com/rpm-software-management/mock/commit/6bb017f7a5a62bcdec...

The reason it doesn't work is because this scriptlet will fail to
locate the file needed to actually do this. The macro was written in
mind for being pointed to the file in the sources directly, rather
than having a path to assume.

Macros for this are the wrong way to do it, for pretty much this reason.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jul 21, 2019 at 01:03:59PM -0400, Neal Gompa wrote:
>  On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; wrote:
>  >
>  > On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
>  > > On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý <msuchy(a)redhat.com&gt;
> wrote:
>  > > >
>  > > > Dne 10. 07. 19 v 9:19 James Antill napsal(a):
>  > > > > 2. adduser/group/etc. => sysusers files
>  > > >
>  > > > For anyone willing to do this in advance on his/her package - this is how
> you can do that:
>  > > >
>  > > >
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
>  > > >
>  > > > Here is relevant FPC ticket:
>  > > >   https://pagure.io/packaging-committee/issue/442
>  > > >
>  > > > Just for the record - this does not make things to run faster. You still
> have to have %pre scriptlets. It is likely even
>  > > > slower as you are running %posttranstrigger as well. The benefit is here
> only that we move toward declarative specification.
>  > > >
>  > >
>  > > That’s also going to fail, because the %pre script executes before the
>  > > file exists. That’s why these guidelines are broken, and why I
>  > > suggested we deal with sysusers differently.
>  >
>  > Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
>  > %sysusers_create is "deprecated. Use %sysusers_create_package instead".
>  >
>  
>  And to note, even this change doesn't work:
>
> https://github.com/rpm-software-management/mock/commit/6bb017f7a5a62bcdec...
>
>  
>  The reason it doesn't work is because this scriptlet will fail to
>  locate the file needed to actually do this. The macro was written in
>  mind for being pointed to the file in the sources directly, rather
>  than having a path to assume. 
Can you explain what exactly is wrong? It looks OK to me.

Zbyszek

> Macros for this are the wrong way to do it, for pretty much this reason.

[Neal Gompa]

On Mon, Jul 22, 2019 at 4:00 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Sun, Jul 21, 2019 at 01:03:59PM -0400, Neal Gompa wrote:
>  > On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
>  > <zbyszek(a)in.waw.pl&gt; wrote:
>  > >
>  > > On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
>  > > > On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý <msuchy(a)redhat.com&gt;
> wrote:
>  > > > >
>  > > > > Dne 10. 07. 19 v 9:19 James Antill napsal(a):
>  > > > > > 2. adduser/group/etc. => sysusers files
>  > > > >
>  > > > > For anyone willing to do this in advance on his/her package - this is
> how you can do that:
>  > > > >
>  > > > >
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
>  > > > >
>  > > > > Here is relevant FPC ticket:
>  > > > >   https://pagure.io/packaging-committee/issue/442
>  > > > >
>  > > > > Just for the record - this does not make things to run faster. You
> still have to have %pre scriptlets. It is likely even
>  > > > > slower as you are running %posttranstrigger as well. The benefit is
> here only that we move toward declarative specification.
>  > > > >
>  > > >
>  > > > That’s also going to fail, because the %pre script executes before the
>  > > > file exists. That’s why these guidelines are broken, and why I
>  > > > suggested we deal with sysusers differently.
>  > >
>  > > Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
>  > > %sysusers_create is "deprecated. Use %sysusers_create_package
> instead".
>  > >
>  >
>  > And to note, even this change doesn't work:
>  >
> https://github.com/rpm-software-management/mock/commit/6bb017f7a5a62bcdec...
>  >
>  >
>  > The reason it doesn't work is because this scriptlet will fail to
>  > locate the file needed to actually do this. The macro was written in
>  > mind for being pointed to the file in the sources directly, rather
>  > than having a path to assume.
>
>  Can you explain what exactly is wrong? It looks OK to me.
>  
How is it supposed to find the mock.conf sysusers file?
%sysusers_create_package expects you to tell it where the file is so
that it can be parsed and expanded at package build time. That's not
being done here...



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 22, 2019 at 07:25:50AM -0400, Neal Gompa wrote:
>  On Mon, Jul 22, 2019 at 4:00 AM Zbigniew Jędrzejewski-Szmek
>  <zbyszek(a)in.waw.pl&gt; wrote:
>  >
>  > On Sun, Jul 21, 2019 at 01:03:59PM -0400, Neal Gompa wrote:
>  > > On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
>  > > <zbyszek(a)in.waw.pl&gt; wrote:
>  > > >
>  > > > On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
>  > > > > On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý
> <msuchy(a)redhat.com&gt; wrote:
>  > > > > >
>  > > > > > Dne 10. 07. 19 v 9:19 James Antill napsal(a):
>  > > > > > > 2. adduser/group/etc. => sysusers files
>  > > > > >
>  > > > > > For anyone willing to do this in advance on his/her package -
> this is how you can do that:
>  > > > > >
>  > > > > >
> https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc...
>  > > > > >
>  > > > > > Here is relevant FPC ticket:
>  > > > > >   https://pagure.io/packaging-committee/issue/442
>  > > > > >
>  > > > > > Just for the record - this does not make things to run faster.
> You still have to have %pre scriptlets. It is likely even
>  > > > > > slower as you are running %posttranstrigger as well. The benefit
> is here only that we move toward declarative specification.
>  > > > > >
>  > > > >
>  > > > > That’s also going to fail, because the %pre script executes before
> the
>  > > > > file exists. That’s why these guidelines are broken, and why I
>  > > > > suggested we deal with sysusers differently.
>  > > >
>  > > > Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
>  > > > %sysusers_create is "deprecated. Use %sysusers_create_package
> instead".
>  > > >
>  > >
>  > > And to note, even this change doesn't work:
>  > >
> https://github.com/rpm-software-management/mock/commit/6bb017f7a5a62bcdec...
>  > >
>  > >
>  > > The reason it doesn't work is because this scriptlet will fail to
>  > > locate the file needed to actually do this. The macro was written in
>  > > mind for being pointed to the file in the sources directly, rather
>  > > than having a path to assume.
>  >
>  > Can you explain what exactly is wrong? It looks OK to me.
>  >
>  
>  How is it supposed to find the mock.conf sysusers file?
>  %sysusers_create_package expects you to tell it where the file is so
>  that it can be parsed and expanded at package build time. That's not
>  being done here... 
Well, the file in this case is given as "mock.conf", and I see a file
with this name in the same directory as the spec file, so everything
seems to be in order.

Zbyszek

[Florian Weimer]

* Ben Cotton:

>  == Dependencies ==
>  N/A (not a System Wide Change) 
Surely this counts as a system-wide change.

It may actually be easier to ban scriptlets altogether, rather than live
in a mixed world where both scriptlets from non-core packages run before
triggers from core packages.

For the rpm-ostree use case, is there any distinction between scriptlet
action on installation or on upgrade?

Thanks,
Florian