Bug 195353
Summary: | Please build network scripts as a separate package | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Denis Ovsienko <denis> | ||||||||
Component: | initscripts | Assignee: | Bill Nottingham <notting> | ||||||||
Status: | CLOSED WONTFIX | QA Contact: | Brock Organ <borgan> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | rawhide | CC: | bill, rvokal | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
URL: | http://etcnet.org/ | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2006-07-24 20:42:41 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 195365 | ||||||||||
Attachments: |
|
Description
Denis Ovsienko
2006-06-14 21:19:45 UTC
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. |