Bug 195353 - Please build network scripts as a separate package
Summary: Please build network scripts as a separate package
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL: http://etcnet.org/
Whiteboard:
Keywords:
Depends On:
Blocks: 195365
TreeView+ depends on / blocked
 
Reported: 2006-06-14 21:19 UTC by Denis Ovsienko
Modified: 2014-03-17 03:00 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-07-24 20:42:41 UTC


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

Description Denis Ovsienko 2006-06-14 21:19:45 UTC
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 21:21:48 UTC
Created attachment 130926 [details]
Patch1, as referred from specfile

Comment 2 Denis Ovsienko 2006-06-14 21:23:24 UTC
Created attachment 130927 [details]
Changes to the specfile.

Comment 3 Denis Ovsienko 2006-06-14 21:25:41 UTC
Created attachment 130928 [details]
src.rpm as I see it

Comment 4 Bill Nottingham 2006-07-24 20:42:41 UTC
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 18:12:14 UTC
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.