Bug 1592330

Summary: [Tracking BZ] Drop unnecessary dependencies on 'initscripts' package
Product: [Fedora] Fedora Reporter: David Kaspar [Dee'Kej] <dkaspar>
Component: initscriptsAssignee: Lukáš Nykrýn <lnykryn>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: john.j5live, jonathan, kdudka, lnykryn, zbyszek
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1610274 (view as bug list) Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1592391, 1592325, 1592335, 1592338, 1592340, 1592342, 1592343, 1592344, 1592345, 1592348, 1592349, 1592350, 1592351, 1592352, 1592354, 1592355, 1592356, 1592357, 1592359, 1592360, 1592362, 1592363, 1592364, 1592366, 1592368, 1592370, 1592372, 1592377, 1592378, 1592379, 1592380, 1592381, 1592382, 1592383, 1592384, 1592385, 1592386, 1592388, 1592389, 1592390, 1592392, 1592393, 1592394, 1592395, 1592396, 1592398, 1592399, 1592400, 1592401, 1592402, 1592403, 1592404, 1592405, 1592406, 1592410, 1592443, 1592444, 1592449, 1727058    
Bug Blocks:    

Description David Kaspar [Dee'Kej] 2018-06-18 12:49:01 UTC
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.

Comment 1 Zbigniew Jędrzejewski-Szmek 2018-06-18 13:02:08 UTC
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.

Comment 2 David Kaspar [Dee'Kej] 2018-06-18 13:41:06 UTC
(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

Comment 3 Pavel Raiskup 2018-06-18 14:50:47 UTC
Is this effort backed up by Fedora guidelines change?

Comment 4 David Kaspar [Dee'Kej] 2018-06-18 15:13:26 UTC
(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? :)

Comment 5 David Kaspar [Dee'Kej] 2018-06-18 15:15:24 UTC
(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

Comment 6 Pavel Raiskup 2018-06-18 15:19:57 UTC
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?

Comment 7 Lukáš Nykrýn 2018-06-18 15:30:59 UTC
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.

Comment 8 Pavel Raiskup 2018-06-18 15:57:13 UTC
(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.

Comment 9 David Kaspar [Dee'Kej] 2018-06-19 11:52:08 UTC
(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. :)

Comment 10 Pavel Raiskup 2018-06-19 20:35:52 UTC
(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.

Comment 11 David Kaspar [Dee'Kej] 2018-06-20 12:48:15 UTC
(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"? :)

Comment 12 Lukáš Nykrýn 2018-06-20 14:49:59 UTC
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.

Comment 13 Jan Kurik 2018-08-14 11:12:02 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 15 Ben Cotton 2019-10-31 18:47:55 UTC
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.