Description of problem: initscripts is an old package and one of the most important parts of a Fedora system. However, I would like it to optionally allow to substitute its network part with an alternative, which is currently impossible. The patches provided introduce initial separation of network scripts into net-scripts package, which conflicts with etcnet package. etcnet package is expected to contain /etc/net configuration system. Version-Release number of selected component (if applicable): The patches provided were diffed at FC5 host, initscripts-8.31.1-1. I additionally attach the resulting SRPM. Thank you.
Created attachment 130926 [details] Patch1, as referred from specfile
Created attachment 130927 [details] Changes to the specfile.
Created attachment 130928 [details] src.rpm as I see it
At this point, I don't think offering in Fedora alternative network configuration is worthwhile; there won't be any tools for it, support in the installer for it, etc. It's best when doing something like this to *not* conflict, if at all possible (see: NetworkManager.)
Bill, respectfully, do you have a specific objection as to why the package cannot be split into sub-packages? Does this break something elsewhere? Is it the overhead of keeping a clean separation between the packages that you are worried about? Or bugzilla complaints that "you broke my etcnet config?" If so, please offer a brief explanation. If you don't want "Conflicts", we need hooks in the right places in initscripts, and more than just a few. etcnet integration could improve rapidly, but you are blocking progress. The existing initscripts are barely functional and cling to an outmoded BSD-centric view of networking, despite a sprinkling of /sbin/ip. Lots of features don't work with each other, like this gem: if [[ "${DEVICE}" =~ '^(eth|bond)[0-9]+\.[0-9]{1,4}$' ]]; then VID=$(echo "${DEVICE}" | LC_ALL=C sed 's/^[a-z0-9]*\.0*//') PHYSDEV=${DEVICE%.*} fi How is this supposed to work after I rename the device to lan0, so as to avoid the unstable MAC <-> device-name problem, and then want to configure vlan on lan0.7? VLAN capability is a function of the device, not the name. :-( [That's in fact why I'm here typing this ...] These many years after Alexey added so much functionality to the kernel, the typical user exercises almost none of it. The few jump through all sorts of hoops to do basic things likes set up policy routing, or do proper traffic control on their DSL lines. etcnet and etcnetconf provide access to LARTC five minutes after it is installed. NetworkManager current makes wifi work; that's about all that it is good for, at the moment. It may improve substantially, but the group of folks working on whiz-bang features consider relatively "static" configs a low priority; they are all focused on AP discovery, DHCP, etc.