| Summary: | [Future EAPI] dounit command to install systemd units | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Chí-Thanh Christopher Nguyễn <chithanh> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | esigra, kensington, nikoli |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://thread.gmane.org/gmane.linux.gentoo.devel/85331/focus=85470 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
|
Description
Chí-Thanh Christopher Nguyễn
2013-05-08 16:57:29 UTC
Wouldn't this be better in an eclass? systemd keeps changing where things get installed. You mean like nsplugins.eclass does? How often does systemd change the location of their unit files, and what do applications do to find out the correct installation place (and can this be replicated by portage)? I'd also say that this is comparable to {do,new}bashcomp and {do,new}pamd that are handled in their eclasses. What would be the advantage of implementing it as a PM command?
It could be turned off in FEATURES without risking side effects from INSTALL_MASK. But probably an eclass variable can achieve something similar. (In reply to comment #4) > It could be turned off in FEATURES without risking side effects from > INSTALL_MASK. But probably an eclass variable can achieve something similar. What are the side effects of INSTALL_MASK which won't exist in FEATURES? What is the advantage of replacing a widely supported general hack with specific hack? (In reply to comment #4) > It could be turned off in FEATURES without risking side effects from > INSTALL_MASK. But probably an eclass variable can achieve something similar. FEATURES=nodoc makes sense because it saves some space. Same for info and man. It's close to useless for things like bash-completion, init files, or systemd units whose footprint is negligible: $ du -s /usr/share/{doc,man,info} /usr/share/bash-completion /etc/init.d /usr/lib/systemd 3380588 /usr/share/doc 103104 /usr/share/man 25068 /usr/share/info 212 /usr/share/bash-completion 400 /etc/init.d 140 /usr/lib/systemd > (In reply to comment #5) With INSTALL_MASK, the user has to be very careful not to accidentally prevent things beside systemd units from being installed. With FEATURES="nounit" this possibility can be reasonably excluded. > (In reply to comment #6) > It's close to useless for things like bash-completion And yet we have USE="bash-completion" for dozens of packages in portage. Is it really a good idea to assume that all systemd units will be installed via the proposed helper. What if upstream's install script puts the systemd units in just the right place? Then ebuild maintainers will be expected to call the dounit helper anyway? In that case, is the dounit helper supposed to remove the installed files if the user has disabled installation of systemd units? I think it can be handled the same as packages directly installing to /usr/share/{doc,info,man}/ when FEATURES=nodoc/noinfo/noman is set.
Alternatively, this situation could be viewed similar to packages installing files to /etc/*.d/ which is sometimes desirable and sometimes not, and left for the package maintainer to decide.
(In reply to Chí-Thanh Christopher Nguyễn from comment #7) > > (In reply to comment #5) > With INSTALL_MASK, the user has to be very careful not to accidentally > prevent things beside systemd units from being installed. With > FEATURES="nounit" this possibility can be reasonably excluded. Doing stuff like this always has measurable risk of breaking your system. Accidentally removing other files is not much different from removing the units -- at some random point in time it can break something, and that's inevitable no matter how fool-proof you try to make it. Much like some apps access their docs in /usr/share/doc and FEATURES=nodoc breaks them. We should work on making things simpler, not more complex. Adding more magical FEATURES with similar function is bad. Adding magical FEATURE which has additional fine-print beside the similar function is even worse. If you believe that INSTALL_MASK is not good enough, then *improve it*. Not fork another useless FEATURE. Look at app-portage/install-mask. Having pre-defined paths for INSTALL_MASK is much better than putting fine details of systemd in PMS or portage. (In reply to comment #10) I do think that the danger from INSTALL_MASK is orders of magnitude greater than of FEATURES=nodoc etc. And stuff like this happens in the real world: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123 This is a really stupid example and it does not help anyone. Stupid mistakes happen and yet you don't cover all sharp edges in your house. As I said, improve INSTALL_MASK. Add pre-defined locations. Let user use them much like he uses FEATURES now. Control it in the repo. Finally drop FEATURES you mentioned and switch it all to proper INSTALL_MASK. Wouldn't: INSTALL_MASK="systemd" be good enough for you? By the way, I'm honestly waiting for the day we are able to drop this aberration of init.d scripts and let OpenRC use unified .service files. Of course, all the fundamentalists will end up with non-bootable systems. (In reply to comment #12) If we tell users to use INSTALL_MASK in its present form then this is what will inevitably happen to some. About your suggestion for improving INSTALL_MASK: it could support sets, where @systemd-units would refer to the known systemd unit locations. If changing INSTALL_MASK semantics is undesired, it might be better to use a new variable name instead of INSTALL_MASK for that. Unlikely to happen. I'd dare say doinitd/doconfd doesn't belong in the PMS either and we may consider moving it out. |
