FS#42231 - [cups] "systemd service names has been renamed" - please disclose the new name, and other things

Attached to Project: Arch Linux
Opened by James (thx1138) - Friday, 03 October 2014, 18:18 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 21 October 2014, 17:51 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

cups-2.0.0-1

On install, there is a note, saying:

> systemd service names has been renamed
> you need to reenable required services

That is a bit "cryptic". Also, "has" should be "have" to match the plural "names", "names have been renamed", referring to cups.service, cups.path, and cups.socket. The reference should also be to "systemd unit names" rather than "service names", since, for instance, "cups.socket" is a systemd "unit" file, but also a "socket" file rather than a "service" file - "systemd cups unit names have been renamed".

It would be polite to disclose the old and new systemd service names, for benefit of the administrator:
Old Name: cups.service
New Name: org.cups.cupsd.service

It would also be polite to point out that the old cups.service should be "stopped" with "sudo systemctl stop cups" _before_ "enabling" the new org.cups.cupsd.service, or _before_ running "sudo systemctl daemon-reload", where otherwise the command will fail with "Failed to stop cups.service: Unit cups.service not loaded.", since the cups.service unit file will then have been already removed from the systemd cached configuration.

It would also be polite to just do this automatically, restarting cupsd, if it is running. I think Debian would do this, but it seems to not be the Arch way.

Also, there are some packages that are explicitly referencing "cups.service" and "cups.socket" that will have to change when cups-2.0.0 is released. For instance, system-config-printer-1.4.4-1 has "/usr/lib/systemd/system/configure-printer@.service" with:

[Unit]
Description=Configure Plugged-In Printer
Requires=cups.socket
After=cups.socket

[Service]
ExecStart=/usr/lib/udev/udev-configure-printer add "%i"

When "org.cups.cupsd.service" is started, there is an error message generated:

systemd[1]: Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket failed to load: No such file or directory.

I don't know how these kinds of communications are coordinated, though there could be a bug filed against system-config-printer after cups-2.0.0 is released. That seems kind of crass though.

With reference to bug https://bugs.archlinux.org/task/40937, I still would suggest a note at least indirectly addressing past "bad advice" from the CUPS and KDE Wiki entries, for instance 'In the file /etc/cups/cups-files.conf, be certain that the group used in the "Group" directive is NOT in the group list in the "SystemGroup" directive, or printing will fail silently.' I also still suggest that a group "lpadmin", with GID "107", be added to /etc/group and to the "SystemGroup" list in cups-files.conf by the cups package to allow for a printer administration group in Arch. Curently, the SystemGroup consists of only "sys" and "root", and the "sys" group, by default of the "filesystem" package, consists of only users "bin" and "root".
Actually, it looks like the cups configure script would automatically add the group "lpadmin" to the default list of groups in SystemGroup if the lpadmin group exists in /etc/group when the cups package is built. Does this need a bug report to the "filesystem" package?


James
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 21 October 2014, 17:51 GMT
Reason for closing:  Fixed
Additional comments about closing:  2.0.0-2
Comment by Andreas Radke (AndyRTR) - Friday, 03 October 2014, 19:12 GMT
I'm going to fix the grammar mistake.

We can add symlinks to old systemd unit names but I guess this wouldn't solve other packages depend on certain running services.

System group discussion should be done in  FS#40937 .
Comment by Andreas Radke (AndyRTR) - Saturday, 04 October 2014, 14:10 GMT
What packages depend on the old cups service names?

We could use additional Alias names in systemd unit files (see man systemd.unit). But I think we should avoid this if possible.

For reference the upstream report where the new names come from: https://www.cups.org/str.php?L3917.
Comment by Evangelos Foutras (foutrelis) - Monday, 06 October 2014, 12:11 GMT
Fedora seems to rename the unit files from org.cups.cupsd.* to simply cups.*

Maybe we could do the same? :)

(Edit: The names inside the service file would need to be updated too: http://pkgs.fedoraproject.org/cgit/cups.git/commit/?id=86c3b85)
Comment by James (thx1138) - Monday, 06 October 2014, 18:26 GMT
> What packages depend on the old cups service names?

Searching Google and grepping through /usr/lib/systemd/ and /usr/share/dbus-1/, I've only come up with system-config-printer 1.4.4-1 in "/usr/lib/systemd/system/configure-printer@.service", and cups-filters 1.0.59-1 in "/usr/lib/systemd/system/cups-browsed.service". There may be others, but not that I can find. We might have to just wait for bug reports.

If the new unit file names are to be used, I suppose the "proper" way to update system-config-printer and cups-filters is to add a dependency on cups<2.0.0 and then bump their versions and add a dependency on cups>=2.0.0, along with changing the unit file names. Otherwise, it would seem that changing all the cups unit file names back to the old names would be reasonable. The old names are certainly easier to type for the "systemctl" commands.

I looked at the reference for the new names - thanks. I see, from Michael Sweet, "I've called the service "org.cups.cupsd" since at some point I think I'll add an org.cups.cups-lpd service as well - this mirrors what we've done for OS X and launchd, and eliminates the dependency on xinetd for LPD server support." This does not seem like an explanation or justification for the very-long-names. Unless someone else can better explain the use of the "org.cups.cupsd" prefix names, as like with the "org.freedesktop." names, I see no reason to complicate the naming. Using the old names would seem to be less hassle all around.

James
Comment by Andreas Radke (AndyRTR) - Saturday, 11 October 2014, 13:24 GMT
I've brought this upstream http://cups.org/pipermail/cups-devel/2014-October/015368.html - let's see where we end.
Comment by Andreas Radke (AndyRTR) - Tuesday, 21 October 2014, 17:51 GMT
We stay with upstream decision for now. Install msg is fixed.

Loading...