Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#51510 - [pkgstats] do not enable pkgstats.timer during install

Attached to Project: Arch Linux
Opened by ua4000 (ua4000) - Sunday, 23 October 2016, 15:59 GMT
Last edited by Doug Newgard (Scimmia) - Sunday, 20 September 2020, 03:48 GMT
Task Type Feature Request
Category Packages: Extra
Status Assigned   Reopened
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 6
Private No


Please remove pkgstats.timer enabling from install - it's no arch way to automatically enable or start software during install.

Instead the wiki should be updated: enable pkgstats.timer after install.

Thanks very much
This task depends upon

Comment by John (graysky) - Sunday, 23 October 2016, 17:00 GMT
There are other packages that enable services and timers upon installation. I am not near my Arch box at the moment but will do a quick look though the ABS tree. Basically just grep out a softlink in the PKGBUILD or readme.install and then grep out 'service' or 'timer' from that subset to identify them.

My 2 cents is that you want the package to do enable the timer for pkgstats simply because without it, the package is useless. Compare that to something optional like sshd or httpd where the user can select when to run the daemon.
Comment by ua4000 (ua4000) - Monday, 24 October 2016, 08:00 GMT
Thanks for your reply!

Arch wiki states in the principles section: "It does not add automation features such as enabling a service simply because the package was installed."

Finding other packages which have the same issue is not a good example to justify another one :-(
But your suggestion would be interesting to find the wrong ones...

If this patch will be applied - we need to put an announce to - to inform users to enable the timer. Also this mention could be some sort of promotion to use the package...

Best regards
Comment by Pierre Schmitz (Pierre) - Monday, 24 October 2016, 14:55 GMT
The valid argument here is that the package is indeed useless without the enabled timer.
Comment by Doug Newgard (Scimmia) - Monday, 24 October 2016, 15:14 GMT
It's useless without the timer, the timer doesn't have to be statically enabled.
Comment by John (graysky) - Monday, 24 October 2016, 19:45 GMT
I agreed with Pierre and Doug. By the way, the following packages also install a softlink to a service or timer effectively enabling the service if I'm not mistaken:

Command to ID them: find /var/abs -type f -name 'PKGBUILD' -print0 | xargs -0 grep 'ln -s' | grep '/usr/lib/systemd'

Comment by Jonathan Roemer (pid1) - Wednesday, 26 October 2016, 01:50 GMT
Depending on how deep we want to go, Pulseaudio enables pulseaudio.socket for the systemd user instance as well. This is quite preferable to upstream's "autospawn" behavior.
Comment by ua4000 (ua4000) - Saturday, 29 October 2016, 08:00 GMT
I'm new to arch (first year), so I'm very thankful for the good wiki and the helpful members!

I read the arch principle, I agree with them.
Then I found pkgstats, found it very useful, but was wondering why it was enabled by default. Since the user can do this too with 3 words, it's a very "simple" package - only few dependencies, no configuration.

I understand, that there are other tasks, where service/timer activation is indeed very helpful, e.g. during core/base installation.

I don't want to insist on my bug report, but maybe the the topic wants to be discussed in general: "Which arch tasks/packages are allowed to enable units during install" - I would like to have a basic rule for arch :-)

Thanks for all comments,
best regards,
Comment by Earnestly (Earnest) - Thursday, 09 August 2018, 05:24 GMT
This package is certainly not the timer, what an absurd conclusion to make.

The timer is merely convenience if a user wants to let pkgstats run on a schedule rather than using the tool directly as and when they choose. The timer certainly is not the majority of this package's function.

As cynically cast aside as "The Arch Way" is these days, and as anti-user this concept of implicit enablement of services is, it could at least use systemd's presets instead of hardcoding these values so that there is no reasonable way for a user to work around or disable this behaviour.

I fail to see how this is "not a bug".
Comment by Alexander Schnaidt (Namarrgon) - Sunday, 28 July 2019, 16:51 GMT
Arch is really the wrong distro for this Opt-Out nonsense, especially with a service that periodically "calls home".
Comment by Eli Schwartz (eschwartz) - Wednesday, 07 April 2021, 05:17 GMT
Thinking more on this... at the very least it seems like it should prefer to enable the timer in the install script rather than in package(), because if people wish to disable it then a package update should not sneakily re-enable it.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 07 April 2021, 12:09 GMT
For statically enabled units the proper way to disable them is `systemctl mask`. Not deleting the symlink in /usr/lib/systemd/system and then wondering why pacman undoes this.

I think the package is fine as-is. Its behavior is not hostile.
Comment by Richard Neumann (rne) - Wednesday, 07 April 2021, 14:58 GMT
The behaviour is not hostile, no. But i consider it unusual.
It should be up to the individual user to enable or disable the respective systemd units.
The package is not useless without the timer, if you e.g. just use it to query package statistics.
Some users might also want to be in control, when to send package statistics, i.e. call pkgstats submit manually.

tl;dr: I would also appreciate the requested change.
Comment by Sascha Shaw (Awebb) - Wednesday, 07 April 2021, 20:53 GMT
Unless I've overlooked something, the only indication that this happens is some

"(1/2) Reloading system manager configuration..."

that could mean a lot of things. I'd personally be fine with a more verbose output informing me about the activated timer (and services in case of other packages doing this).