Description of problem: There are still quite a number of packages out there which depend on 'initscripts' package for no longer valid reason. For future work we need to decrease the number of dependant packages as much as possible. This is a tracking BZ for all the packages depending on initscripts for some reason. Version-Release number of selected component (if applicable): https://koji.fedoraproject.org/koji/buildinfo?buildID=1092002 Additional info: Please, do not post any comments directly in this bug. Create new bug if necessary.
I strongly suggest putting the name of the package as the first word in your bugreports. Bugzilla doesn't always make it easy to see for which package the bug is in listings.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > I strongly suggest putting the name of the package as the first word in your > bugreports. Bugzilla doesn't always make it easy to see for which package > the bug is in listings. Uh, the pain of doing this manually... o.O I really need to write myself some script for this... :D
Is this effort backed up by Fedora guidelines change?
(In reply to Pavel Raiskup from comment #3) > Is this effort backed up by Fedora guidelines change? Why would it be? In other words, why should packages have unnecessary dependencies? :)
(In reply to David Kaspar [Dee'Kej] from comment #4) > (In reply to Pavel Raiskup from comment #3) > > Is this effort backed up by Fedora guidelines change? In short, no it isn't backed up by Fedora guidelines change. At least I don't know about any guideline change related to this. The only thing I can point you right now is this: https://fedoraproject.org/wiki/Packaging:Guidelines#Initscripts
Aha, I probably misinterpreted the reasons for this tracker. Do I understand it correctly that it is not an attempt to switch spec files (%post/%postun scriptlets, etc.) from using service <SERVICE> condrestart into systemctl condrestart <SERVICE> That said, is it still valid to depend on initscripts for /sbin/service to work?
Well speaking about that. If you need service, you are probably shipping initscripts and If I am not mistaken that is prohibited by our policy unless you have an exception.
(In reply to Lukáš Nykrýn from comment #7) > Well speaking about that. If you need service, you are probably shipping > initscripts and If I am not mistaken that is prohibited by our policy unless > you have an exception. The assumption isn't correct. Consider I'm maintaining spec file which is supposed to work both on el6 and Fedora Rawhide, and I don't want to have %if 0%{?fedora} >= X || 0%{?rhel} >= Y in scriptlets.
(In reply to Pavel Raiskup from comment #8) > The assumption isn't correct. Consider I'm maintaining spec file > which is supposed to work both on el6 and Fedora Rawhide, and I don't want > to have %if 0%{?fedora} >= X || 0%{?rhel} >= Y in scriptlets. I understand your reason. On the other hand, having the %if conditionals is common practice in specfiles, and installing initscripts just to install/enable some service is quite inconsiderate to end-users (e.g. in mimimal OS images or containers). We would like to see that no package in the future would depend on initscripts, so the package could be uninstalled from the system if user wants, thus initscripts becoming useful for only few (mostly) 3rd party/proprietary software (which still relies on initscripts). On the other hand, if we see many people / packages depending on the /usr/sbin/service so much (I understand the convenience of using it), it might be worth trying to completely separate the 'service' into a new package. I'll have to think about it more. For now, it would be good to at least get some statistics, on how many packages still need the initscripts and for what reasons. :)
(In reply to David Kaspar [Dee'Kej] from comment #9) > On the other hand, if we see many people / packages depending on the > /usr/sbin/service so much (I understand the convenience of using it), it > might be worth trying to completely separate the 'service' into a new > package. Or provide /sbin/service in systemd package? AFAIK that the service command will be needed indefinitely to comply with LSB.
(In reply to Pavel Raiskup from comment #10) > Or provide /sbin/service in systemd package? AFAIK that the service command > will be needed indefinitely to comply with LSB. This was actually my other idea, and it kind of makes sense that systemd would ship it, but... I really don't expect systemd to accept it. Maybe it could be a separate package, and systemd might have weak dependency on it, like "suggests"? :)
I don't like that, usage of service command should be tight to initscripts. The use-case mentioned here is a misuse in my eyes and brings an unnecessary dependency. And that is something we should always try to fix. Generally speaking, you should use the condition. If you have a specific use-case, then we should discuss it, but it is not for this Bugzilla.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Closing, since this tracker is no longer needed. All packages are now free from initscripts. The only exception is the audit, which is using initscripts-service subpackage.