Re: Potential changes to systemd RPM macros

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 26, 2023 at 07:15:42AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 25, 2023 at 10:45:30AM -0400, Andrea Bolognani wrote:
> > On Tue, Jul 25, 2023 at 10:51:04AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > > I think it'd be more effiecient to go with the (slightly ugly, no
> > > disagreement here) seven line %trigger scriptlet. And and then work
> > > with upstream to implement a generic solution that can be used by all
> > > packages. It seems to me that the work put into implementing a custom
> > > solution in libvirt would be wasted if you want to work with upstream
> > > on a completely different general solution soon after.
> >
> > Another way to look at it is that I *already* put all that work in,
> > and the solution I've proposed for libvirt has been tested quite
> > thoroughly in a number of install and upgrade scenarios. In order to
> > adopt the %trigger based solution, I will have to spend more time on
> > developing and testing another implementation.
>
> That's fine. I only saw some links to emails, and it didn't know that
> those have already been applied and tested. My goal was to minimize
> overall effort, not to increase it ;)

They've been tested and, as of yesterday, fully reviewed, but not yet
applied.

If I understand correctly and you have no strong objections to them
being merged, I think I will stick to my original plan of addressing
the immediate issue in libvirt by pushing those patches, and work on
a more long-term solution that lives in systemd as a follow-up
instead of investigating the %trigger route further.

The lack of strong objections on the Fedora side will hopefully
assuage Daniel's concerns as well.

> > I feel that having packages call systemctl directly instead of going
> > through the %systemd_* macros is an anti-pattern that shouldn't be
> > encouraged.
>
> That's a valid point.
>
> > The current set of macros already includes both %systemd_postun and
> > %systemd_postun_with_restart, so adding %systemd_postun_with_reload
> > or something along those lines doesn't seem like a stretch.
>
> → https://github.com/systemd/systemd/pull/28521

Neat!

-- 
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux