openrc stabilization update
 

All,

looking at the tracker, I see that only two bugs remain which block
stabilization of openrc:

http://bugs.gentoo.org/213988
http://bugs.gentoo.org/302116

What does everyone think? Are there any other bugs we should fix before
targeting a release for stabilization?

I suppose one question I need to ask is the oldnet vs newnet question.
The git repository defaults to building and installing the newnet
option, and we make oldnet the default in the ebuild.

People migrating from stable will know the oldnet option, and this is
the only way to configure the network scripts that is actually covered
in our documentation.

Do we want to switch the upstream repository to make oldnet the default?

What about newnet. Should we keep it at all? If we do, should we put
it behind a use flag which would be off by default?

Any comments/feedback are definitely welcome on this issue, and on any
other bugs you think should block the openrc tracker at
http://bugs.gentoo.org/295613.

Thanks,

William

openrc stabilization update
 

On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs <williamh@gentoo.org> wrote:
> I suppose one question I need to ask is the oldnet vs newnet question.
> The git repository defaults to building and installing the newnet
> option, and we make oldnet the default in the ebuild.
>
> People migrating from stable will know the oldnet option, and this is
> the only way to configure the network scripts that is actually covered
> in our documentation.
>
> Do we want to switch the upstream repository to make oldnet the default?
>
> What about newnet. *Should we keep it at all? *If we do, should we put
> it behind a use flag which would be off by default?
>

Is there any advantage to using newnet over oldnet? If there aren't
any advantages, we should not attempt to support it (even as an
optional feature). Old-net by default, no use-flag for newnet; people
can use EXTRA_ECONF if they *really* want to use it.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

openrc stabilization update
 

On Mon, Sep 20, 2010 at 06:05:46AM +0530, Nirbheek Chauhan wrote:
> On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs <williamh@gentoo.org> wrote:
> > I suppose one question I need to ask is the oldnet vs newnet question.
> > The git repository defaults to building and installing the newnet
> > option, and we make oldnet the default in the ebuild.
> >
> > People migrating from stable will know the oldnet option, and this is
> > the only way to configure the network scripts that is actually covered
> > in our documentation.
> >
> > Do we want to switch the upstream repository to make oldnet the default?
> >
> > What about newnet. ??Should we keep it at all? ??If we do, should we put
> > it behind a use flag which would be off by default?
> >
>
> Is there any advantage to using newnet over oldnet? If there aren't
> any advantages, we should not attempt to support it (even as an
> optional feature). Old-net by default, no use-flag for newnet; people
> can use EXTRA_ECONF if they *really* want to use it.

If I go this route, I'll probably just get rid of newnet in the next
release entirely.

newnet is a single script, "network", which sets up all of the static
routes and static interfaces.

It is small and simple, but the disadvantage of it is that you can't
stop/start a single interface.

William

openrc stabilization update
 

On Sunday, September 19, 2010 21:22:06 William Hubbs wrote:
> On Mon, Sep 20, 2010 at 06:05:46AM +0530, Nirbheek Chauhan wrote:
> > On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs wrote:
> > > I suppose one question I need to ask is the oldnet vs newnet question.
> > > The git repository defaults to building and installing the newnet
> > > option, and we make oldnet the default in the ebuild.
> > >
> > > People migrating from stable will know the oldnet option, and this is
> > > the only way to configure the network scripts that is actually covered
> > > in our documentation.
> > >
> > > Do we want to switch the upstream repository to make oldnet the
> > > default?
> > >
> > > What about newnet. ??Should we keep it at all? ??If we do, should we
> > > put it behind a use flag which would be off by default?
> >
> > Is there any advantage to using newnet over oldnet? If there aren't
> > any advantages, we should not attempt to support it (even as an
> > optional feature). Old-net by default, no use-flag for newnet; people
> > can use EXTRA_ECONF if they *really* want to use it.
>
> If I go this route, I'll probably just get rid of newnet in the next
> release entirely.
>
> newnet is a single script, "network", which sets up all of the static
> routes and static interfaces.
>
> It is small and simple, but the disadvantage of it is that you can't
> stop/start a single interface.

i suggested in a previous thread that we depreciate "newnet" if not kill it
off entirely. the "oldnet" stuff should become the default once again.
-mike

openrc stabilization update
 

On Sun, 19 Sep 2010 19:27:50 -0500
William Hubbs <williamh@gentoo.org> wrote:

> What about newnet. Should we keep it at all? If we do, should we put
> it behind a use flag which would be off by default?

I insist on keeping it as I use it myself. The new approach seems more
desktop-targeted to me. The network script sets the domain name
and bonding, dhcpcd script starts dhcpcd (which can control more than
a single interface) and wpa_supplicant script is responsible for wifi.

--
Best regards,
Michał Górny

openrc stabilization update
 

On Sun, 19 Sep 2010 19:27:50 -0500
William Hubbs <williamh@gentoo.org> wrote:
> I suppose one question I need to ask is the oldnet vs newnet question.
> The git repository defaults to building and installing the newnet
> option, and we make oldnet the default in the ebuild.
>
> People migrating from stable will know the oldnet option, and this is
> the only way to configure the network scripts that is actually covered
> in our documentation.

Pick one way of configuration. One and only one. I'm not going to completely rewrite hundreds of pages of documentation more than once, so whichever you choose (ideally the way that I've already covered in the OpenRC migration guide), just choose one. None of this "old way now and then something completely different in the future once it's stabilized" within the same package.

One for simplicity, one for somewhat-happy tech writers, one for the win.

openrc stabilization update
 

Hi!

On Mon, 20 Sep 2010, Michał Górny wrote:
> William Hubbs <williamh@gentoo.org> wrote:
> > What about newnet. Should we keep it at all? If we do, should we put
> > it behind a use flag which would be off by default?
>
> I insist on keeping it as I use it myself. The new approach seems more
> desktop-targeted to me. The network script sets the domain name
> and bonding, dhcpcd script starts dhcpcd (which can control more than
> a single interface) and wpa_supplicant script is responsible for wifi.

I'm with nightmorph: we should have exactly one way to configure
networking (i.e. exactly one syntax).

That said, switching to newnet would be a huge mess for everybody
who runs servers: DHCP is uncommon there, WLAN is very unusual,
as a result, they would not only have to switch the way they
configure their nets (people don't like that kind of stuff if the
machine is 400 miles away); they would also have to find a way to
build their setups in the new "language". Servers tend to have
more complicated setups network-wise than workstations (think
firewalls, VPN endpoint, traffic observation, ...).

So we would make things more complicated for a large user base
for the benefit of desktop users who can't get DHCP/Wifi to work
with oldnet. I doubt the latter is a larger group than the
former.

Regards,
Tobias



--
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c

openrc stabilization update
 

On Mon, Sep 20, 2010 at 10:29 AM, Tobias Klausmann <klausman@gentoo.org> wrote:
> Hi!
>
> On Mon, 20 Sep 2010, Michał Górny wrote:
>> William Hubbs <williamh@gentoo.org> wrote:
>> > What about newnet. Â*Should we keep it at all? Â*If we do, should we put
>> > it behind a use flag which would be off by default?
>>
>> I insist on keeping it as I use it myself. The new approach seems more
>> desktop-targeted to me. The network script sets the domain name
>> and bonding, dhcpcd script starts dhcpcd (which can control more than
>> a single interface) and wpa_supplicant script is responsible for wifi.
>
> I'm with nightmorph: we should have exactly one way to configure
> networking (i.e. exactly one syntax).
>
> That said, switching to newnet would be a huge mess for everybody
> who runs servers: DHCP is uncommon there, WLAN is very unusual,
> as a result, they would not only have to switch the way they
> configure their nets (people don't like that kind of stuff if the
> machine is 400 miles away); they would also have to find a way to
> build their setups in the new "language". Servers tend to have
> more complicated setups network-wise than workstations (think
> firewalls, VPN endpoint, traffic observation, ...).

the same is true for everyone who already runs newnet (like me). in
fact, i do not even use the newnet conf.d stuff, but rather take
advantage of support for /etc/ifup.eth* in /etc/init.d/network. that
way i can configure the networking with iproute2 or any other tool
that i already know the syntax of. no need to learn ridiculously
convoluted array syntax foo for /etc/init.d/net.eth*.

so please just keep the network init script as a use flag or extra
package or something, so that one is not forced to use the old net
stuff (again).

P.S.: newnet does not in any way force you to use DHCP or WLAN or
anything like that, so please stop spreading misinformation.

-Bene

openrc stabilization update
 

On 09/20/2010 11:10 AM, Benedikt Böhm wrote:
> the same is true for everyone who already runs newnet (like me). in
> fact, i do not even use the newnet conf.d stuff, but rather take
> advantage of support for /etc/ifup.eth* in /etc/init.d/network. that
> way i can configure the networking with iproute2 or any other tool
> that i already know the syntax of. no need to learn ridiculously
> convoluted array syntax foo for /etc/init.d/net.eth*.

if you are using /etc/ifup.eth* what would prevent having oldnet run
those as the newnet do?

lu

--

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

openrc stabilization update
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/19/2010 09:22 PM, William Hubbs wrote:
> On Mon, Sep 20, 2010 at 06:05:46AM +0530, Nirbheek Chauhan wrote:
>> On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs <williamh@gentoo.org>
wrote:
>>> I suppose one question I need to ask is the oldnet vs newnet question.
>>> The git repository defaults to building and installing the newnet
>>> option, and we make oldnet the default in the ebuild.
>>>
>>> People migrating from stable will know the oldnet option, and this is
>>> the only way to configure the network scripts that is actually covered
>>> in our documentation.
>>>
>>> Do we want to switch the upstream repository to make oldnet the default?
>>>
>>> What about newnet. ??Should we keep it at all? ??If we do, should we put
>>> it behind a use flag which would be off by default?
>>>
>>
>> Is there any advantage to using newnet over oldnet? If there aren't
>> any advantages, we should not attempt to support it (even as an
>> optional feature). Old-net by default, no use-flag for newnet; people
>> can use EXTRA_ECONF if they *really* want to use it.
>
> If I go this route, I'll probably just get rid of newnet in the next
> release entirely.
>
> newnet is a single script, "network", which sets up all of the static
> routes and static interfaces.
>
> It is small and simple, but the disadvantage of it is that you can't
> stop/start a single interface.
>
> William
>

Why can't we keep both? There are strong advantages/disadvantages
either way and there are users invested in both new/oldnet. I know
this is more work on doc writers, but I don't think that will equal
the pain users will experience being forced one way or another.

- --
Anthony G. Basile, Ph.D.
Gentoo Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyXO30ACgkQl5yvQNBFVTVhuQCbBG2owroUS8 ZFko2oEE1ZIYgQ
rZ0An19HgxWA9Ltat3owfIB5cvqjdRGE
=YqFX
-----END PGP SIGNATURE-----