[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

Colin Guthrie mageia at colin.guthr.ie
Tue Aug 23 15:45:31 CEST 2011

'Twas brillig, and Thierry Vignaud at 23/08/11 14:34 did gyre and gimble:
> On 23 August 2011 10:55, Colin Guthrie <mageia at colin.guthr.ie> wrote:
>>> err... drakx-net's code is heavily used by other tools such as:
>>> - drakx-installer
>>> - mgaonline
>>> - ...
>>> So I think we still want to keep drakx-net
>> Perhaps, but then a more interesting question is "what bits of drakx-net
>> are used in mgaonline and drax-installer?" Just stating that they are
>> used there as a reason to keep it isn't really a good argument IMO.
> drakx-installer uses most of interesting bits of drakx-net (ake network
> detection & set up, ...)
>> Asbestos is used in fire retardant wall insulation, but it's not a good
>> argument to keep it considering the world has moved on and we now know
>> the dangers of working with that material.
> OK, give me the NM patches for the installer :-)

If I get time, I think it would be worth looking at. Obviously (just
like in one of my replies) I'm far better at *talking* than *doing* too :D

> Seriously, without trolling, we just cannot drop drakx-net until we got
> something else for the installer.
> Dunno what does anaconda these days btw?

Not sure. I'll have to take a look at that, but it would be interesting
to see if it's more integrated into NM now.

>> So what does mgaonline need to work with drakx-net? Does it just need to
>> know if you are online or not? If so why not use NM's dbus service to do
>> that? It could eventually know whether you are on a paid/metered
>> connection (this is not yet supported by NM but there has been some talk
>> about it) or a "free" connection - a fast vs. slow connection etc. It
>> could make intelligent, informed decisions, not just "is the user online
>> - no matter how crappily?"
> mgaonline has less needs, basically detecting network connectivity
> but those are shared with the installer, so even if the lower level
> part would change, there's no readon not to have a common perl
> layer hiding the low level bits instead of making both interfaces NM

Agreed. Perhaps my terminology is incorrect here. I'm not against such
an abstraction layer and even maintaining a if (nm) { new() } else {
old(); } approach for a release or two depending on need.



Colin Guthrie

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

More information about the Mageia-dev mailing list