Bug 195353 - Please build network scripts as a separate package
Please build network scripts as a separate package
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
http://etcnet.org/
:
Depends On:
Blocks: 195365
  Show dependency treegraph
 
Reported: 2006-06-14 17:19 EDT by Denis Ovsienko
Modified: 2014-03-16 23:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-24 16:42:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch1, as referred from specfile (5.41 KB, patch)
2006-06-14 17:21 EDT, Denis Ovsienko
no flags Details | Diff
Changes to the specfile. (4.46 KB, patch)
2006-06-14 17:23 EDT, Denis Ovsienko
no flags Details | Diff
src.rpm as I see it (821.59 KB, application/octet-stream)
2006-06-14 17:25 EDT, Denis Ovsienko
no flags Details

  None (edit)
Description Denis Ovsienko 2006-06-14 17:19:45 EDT
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.
Comment 1 Denis Ovsienko 2006-06-14 17:21:48 EDT
Created attachment 130926 [details]
Patch1, as referred from specfile
Comment 2 Denis Ovsienko 2006-06-14 17:23:24 EDT
Created attachment 130927 [details]
Changes to the specfile.
Comment 3 Denis Ovsienko 2006-06-14 17:25:41 EDT
Created attachment 130928 [details]
src.rpm as I see it
Comment 4 Bill Nottingham 2006-07-24 16:42:41 EDT
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.)
Comment 5 Bill Rugolsky, Jr. 2006-11-16 13:12:14 EST
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.

Note You need to log in before you can comment on or make changes to this bug.