This request makes sense, but it would require more work than just a simple spec change. I quickly peeked into packages requiring chkconfig and after few seconds I found an example of a package that would break after that change. Atlas uses alternatives in scriptlets but requires chkconfig.

If anyone is willing to go through the fedora packages and fix the dependecies, I would be open to split the package, but to be honest, I have more important things on my plate then this.

I'm well aware of the requirements outside of the spec change (I've only been using Fedora/RHL/RHEL for 22 years).

I just wanted to verify I wasn't going to get yelled at if I started the process.

For reference there's:
172 packages with a dep on chkconfig (a lot of subpackages/dupes in that output)
81 that need /usr/sbin/alternatives
48 that need /usr/sbin/update-alternatives

With a lot of overlap in the 3

> I just wanted to verify I wasn't going to get yelled at if I started the
> process.

Nope, I promise I won't yell. This change make sense. Someone just need to go through the packages that only have chckofig dependency and call alternatives in the spec file. That is probably easy to script. But then report and fix the broken ones, which could be harder.

In my dreams I have a new alternatives implementation with new cool features like setting alternatives per services... And such project would live outside the chkonfig repo, so it would be a separate package anyway.

> In my dreams I have a new alternatives implementation with new cool features
> like setting alternatives per services... And such project would live
> outside the chkonfig repo, so it would be a separate package anyway.

That would be easier to do even once we have the alternatives in a separate sub package as we can just kill the subpackage and have a new one called the same

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

(In reply to Lukáš Nykrýn from comment #4)
> > I just wanted to verify I wasn't going to get yelled at if I started the
> > process.
> 
> Nope, I promise I won't yell. This change make sense. Someone just need to
> go through the packages that only have chckofig dependency and call
> alternatives in the spec file. That is probably easy to script. But then
> report and fix the broken ones, which could be harder.

So thinking this through some more I think the easiest way to do this is to add a "Provides: alternatives" to the current chkconfig package, go through the list of packages that requires chkconfig and where they just need alternatives update the requires and then once that is done we can split out the alternatives functionality. Are you OK with this approach?

I would rather follow the guidelines here and fix packages to require the binary.

https://fedoraproject.org/wiki/Packaging:Alternatives

(In reply to Lukáš Nykrýn from comment #8)
> I would rather follow the guidelines here and fix packages to require the
> binary.
> 
> https://fedoraproject.org/wiki/Packaging:Alternatives

Except there's plans to kill off binary provides/requires (see a number of threads of devel@ recently which means everything would have to be done twice and that becomes a problem, I don't have the time. The above is still within guidelines.

Ok, I will the Provide to upstream and rawhide.

https://github.com/fedora-sysv/chkconfig/commit/a1021e1c3cb8198ed0ae73a7773b0e0fd37832d6

chkconfig-1.11-2.fc30

I believe I've fixed up all the alternatives packages in F-30+ (I actually did it some time ago). I've pushed this to rawhide so we can check to see if I've missed any but I believe it's now alll good.

Just a small update here, one of my colleagues is currently working on ripping of the alternatives even from upstream chkconfig. The reason is that alternatives will probably need some bigger rewrite (they don't work at all on rpm ostree based systems).

(In reply to Lukáš Nykrýn from comment #14)
> Just a small update here, one of my colleagues is currently working on
> ripping of the alternatives even from upstream chkconfig. The reason is that
> alternatives will probably need some bigger rewrite (they don't work at all
> on rpm ostree based systems).

Is there a timeframe for this? A new stand alone alternatives package can easily obsolete it once it's ready to go.

Let's say a month, and if it is not done till then, please feel free to shout at me :-)

(In reply to Lukáš Nykrýn from comment #16)
> Let's say a month, and if it is not done till then, please feel free to
> shout at me :-)

there will be no need to shout, take the time required to get it right. The work I did to fix package deps and related bits is needed both ways, this sorts out a problem for me in the interim while the rest of it settles out. Multi step process, we'll get there :)

For reference the split has been mostly smooth. The only real issue was the livecds still depend on initscripts/chkconfig to setup live users and the like, and chkconfig was only being pulled in for Workstation via java. The livecd issue has been worked around by explicitly pulling in chkconfig but there's a long running RFE to convert it to something else. Java has also been fixed.

https://bugzilla.redhat.com/show_bug.cgi?id=739446
https://pagure.io/fedora-kickstarts/pull-request/502#

chkconfig-1.11-4.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-80660ccea1

chkconfig-1.11-4.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-80660ccea1

chkconfig-1.11-4.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.