On 7/30/19 6:10 PM, Jason L Tibbitts III wrote:
"PM" == Panu Matilainen <pmatilai@xxxxxxxxxx> 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<
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
