Re: [system-tools] distro / functionality detection

[Carlos Garnacho <carlosg gnome org>]

Hi Jürg,

First of all, sorry for the really late reply, I've left this one for
too long :(

On Wed, 2004-07-21 at 09:38 +0200, Jürg Billeter wrote: 
> Hi
> 
> The GNOME System Tools seem to be very nice tools but I have a concern
> and a proposal regarding distro / functionality detection. In short: You
> are using the imake approach but I'd welcome an autotools approach if
> you know the philosophy behind these two. This has nothing to do with
> your build system...
> 
> AFAIK g-s-t (and imake) configures itself on startup according to the
> distro they are running; g-s-t looks for a file where it can recognize
> that it's Debian Woody or Mandrake x.y or RedHat a.b, and then g-s-t
> does a lookup of the distro name and version in a table to see which
> functionality should provided. Now the problem with this approach is
> that forea each distro (version) g-s-t needs to be modified. There are
> probably many Debian based distros out there but as long as they don't
> tell g-s-t "I am Debian Sarge" or send you a patch, they won't be
> recognized.
> 
> I for example am co-maintainer of a really tiny distro whose networking
> support is ifupdown-based (i.e. Debian Sarge) and whose initscripts
> follow the LSB rules; I could just send you a patch to add support for
> our distro but that just doesn't make sense as there are thousands of
> distros...
> 
> What I propose is the feature-based (or autotools) approach. So, instead
> checking on startup whether Debian Sarge or Fedora Core 2 is running,
> just check for the needed features. I.e. check whether ifupdown manages
> the network system by looking for the /etc/networks/interfaces file,
> check whether the bootscripts have a chkconfig line the LSB typical
> lines in there.

I see your point, and there was some time (back to when I joined the
project) that I though like you, but now I really think that following
heuristics in this case is wrong/dangerous because:

- while there are heuristics that seem easy to guess (such as the "use
ifup/ifdown if available, if not use ifconfig [1]) are others that might
not (i.e: format change in a same file between distros or versions of
the same distro [2])

- this would risk tools to break new/untested distributions while
they're claiming that they are doing everything right, and it would mean
a constant potential unstable status, right now it at least complains if
the distribution isn't supported, making the tools more reliable

- right now there are lots of infrastructure, adding a new distro would
not mean adding more than 30/40 lines of code [3] (if it derives from an
already supported distro)


> 
> Keep up the great work

Thanks :)

	Carlos

> 
> PS: Restructured similar to the top-down proposal of Havoc and
> "autotooled" I'd love to see the GNOME System Tools in the desktop
> release.
> 

[1] Note that this is only valid for eth-like interfaces, for ppp
devices we have the same mess with ifup/ppp-go/pon/pppd...

[2] as a small example, ESSID parameter
in /etc/sysconfig/networking/devices/ifcfg-xxx was changed to
WIRELESS_ESSID in some distros some time ago, this is impossible to
guess if you're creating a config file from scratch

[3] I know, right now there are no docs about how to do that, I should
move my butt and do it, really :/