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.
|