Arch Linux

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.

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." https://wiki.archlinux.org/index.php/Arch_Linux

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...

Nevertheless:
If this patch will be applied - we need to put an announce to https://www.archlinux.org/feeds/news/ - to inform users to enable the timer. Also this mention could be some sort of promotion to use the package...

Best regards
ua4000

The valid argument here is that the package is indeed useless without the enabled timer.

It's useless without the timer, the timer doesn't have to be statically enabled.

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'

[core]/logrotate
[core]/lvm2
[core]/man-db
[core]/mlocate
[core]/shadow
[extra]/hylafax
[extra]/mariadb
[extra]/pkgstats
[community]/startdde
[community]/hidepid

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.

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,
ua4000

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".

Arch is really the wrong distro for this Opt-Out nonsense, especially with a service that periodically "calls home".

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.

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.

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.

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).

Mhhh, the whole thing looks a bit strange to me. If the maintainer wants a timer inside the package, the timer should work for systemd out of the box, in the sense of that no error should be reported by systemd if the user enable it manually. Right now, it doesn't, because there is a missing target for systemd like WantedBy=timers.target in the timer file. If there shouldn't be a timer at all, just remove the file, otherwise the "bug" should be fixed. Clarification: I don't wanna have automatic enable timer or a notice that a timer should be enable after installation! But in the case of a user want to use (enable) a timer it should be works flawless. I think this should be right "Arch way". :-)

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.