Gentoo Archives: gentoo-dev

From: Richard Freeman <rich0@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] openrc stabilization update
Date: Mon, 20 Sep 2010 13:37:48
Message-Id: 4C97639A.3000207@gentoo.org
In Reply to: Re: [gentoo-dev] openrc stabilization update by "Michał Górny"
1 On 09/20/2010 07:06 AM, Michał Górny wrote:
2 > I guess quite a good solution for now might be enabling newnet through
3 > an USE flag, being masked in the profile by default. That would satisfy
4 > the oldnet compatibility requirement for users, while the small group
5 > preferring newnet could still benefit from it.
6 >
7
8 This pretty-much guarantees that arch testers/etc will end up testing it
9 one way or the other, and not both. That could lead to QA issues when
10 packages work fine for some users and not for others.
11
12 Granted, this is mainly a concern for lower-level network-config related
13 apps.
14
15 I'd hate to be the maintainer of an ebuild that needs to take into
16 account multiple network configuration options.
17
18 I still haven't heard a good reason as to why we need two. I'm running
19 oldnet (baselayout-1), and changing to newnet would be a pain, but I
20 don't expect the distro to take this into account for my sake when
21 making decisions like this. I'm sure people running newnet feel similarly.
22
23 The only argument I've heard for newnet is that it is more DHCP-friendly
24 or something like that (not that DHCP is required). However, I've never
25 found getting DHCP to work particularly difficult - it practically comes
26 like that by default (just emerge dhcpcd and add the interface to your
27 init.d). I imagine wireless might be more complex.
28
29 One argument I've heard against newnet is that you can't bring
30 individual interfaces up and down. That sounds like a potential
31 drawback. Granted, most of the sorts of things that I'd like to
32 conditionally bring up (vpn, ipv6 tunnel, etc) probably won't use the
33 network scripts anyway.
34
35 Rich

Replies

Subject Author
Re: [gentoo-dev] openrc stabilization update Eray Aslan <eray.aslan@×××××××.tr>