add: yumex and yumex-updater#13241
Conversation
![hamachitan[bot]](https://avatars.githubusercontent.com/u/252208892?s=60&v=4){kind=small}
CodeforEvolution
force-pushed
the
yumex-ng
branch
2 times, most recently
from
a2b5c92 to
20f47e3
Compare
|
|
||
| %files -n %{name}-updater | ||
| %{_userunitdir}/%{name}-updater.service | ||
| %{_prefix}/lib/systemd/user-preset/*%{name}-updater.preset |
There was a problem hiding this comment.
This one's interesting. It's against Fedora policy to auto-enable services on package install... What does the service do?
There was a problem hiding this comment.
Fedora policies can just don't apply here so we could allow this if we know what this does
There was a problem hiding this comment.
The yumex-updater service runs a Python-based application that creates an icon in the tray and polls for updates at a configurable interval. It also allows you trigger an update check manually, and open the primary application from the tray icon. Perhaps this could be ran using the XDG autostart mechanism instead?
There was a problem hiding this comment.
Yeah since this is not vital functionality, I'm leaning towards following Fedora policy here unless you/anyone else have objections.
There was a problem hiding this comment.
In that case, should I just remove the preset installation? (However, I do worry about how someone would discover the existence of the updater service file.)
There was a problem hiding this comment.
Keep in mind that instructions in scriptlets are unlikely to be seen.
There was a problem hiding this comment.
I looked at KDE's Discover for inspiration, and I can see it uses the XDG autostart mechanism for its own separate notifier application. I'll swing this idea at the author of Yumex, but for now, I'll leave the preset in place.
There was a problem hiding this comment.
This is true, after thinking it over more, I believe we should rely on the XDG auto start mechanism that seems to work here, and let upstream know the .preset shouldn't be installed by default instead.
Allowing non-branding packages to ship .preset files can be dangerous.
There was a problem hiding this comment.
let upstream know the .preset shouldn't be installed by default instead
While this is a Fedora-specific program, I'd like to point out this is a Fedoraism and Arch and Debian based distros have no such policy since installing a program that needs a service to work can be considered implicit consent to enable that service (something I'd personally agree with).
There was a problem hiding this comment.
Debian is slowly changing to centralized presets. Prior to dh-systemd switching to presets, every service was activated on install, but it is a bad policy and results in instability in enough scenarios that it is finally changing.
For what it's worth, Mageia; openSUSE; and OpenMandriva also follow the centralized preset model.
- Introducing yumex-ng, a ground up rewrite of Yumex with GTK4 and libadwaita. - Includes an auto-update script.
CodeforEvolution
force-pushed
the
yumex-ng
branch
from
20f47e3 to
422929b
Compare
| %postun | ||
| if [ $1 -eq 0 ] ; then | ||
| /bin/touch --no-create %{_hicolordir} &>/dev/null | ||
| /usr/bin/gtk-update-icon-cache %{_hicolordir} &>/dev/null || : |
There was a problem hiding this comment.
I'd recommend testing these icon cache post scripts to see if they even matter, I doubt they do anything.
There was a problem hiding this comment.
Yeah, remove all the non-systemd post scripts
5 participants
I was provided permission by the author of Yumex NG to be the package maintainer:
timlau/yumex-ng#184