[arch-projects] [PATCH 1/7] config: add /etc/hostname support

Allan McRae allan at archlinux.org
Thu Oct 27 20:57:40 EDT 2011

On 28/10/11 09:35, Tom Gundersen wrote:
> On Thu, Oct 27, 2011 at 2:11 PM, Allan McRae<allan at archlinux.org>  wrote:
>> On 27/10/11 10:28, Dan McGee wrote:
>>> Does anyone else still hold onto the old days where configuration was
>>> primarily a single file rather than scattered buckshot in /etc/? If it
>>> is just me I'll shut up, but I've always loved that fact.
>> I have to agree here.  I was fine with the locale stuff moving out as I saw
>> the advantage (control over individual locale components) and that putting
>> those in rc.conf would be messy.   But I do not see what advantage moving
>> hostname out of rc.conf brings.
> I'm happy to drop this patch if it rubs people the wrong way. I'll
> give you my rationale first though, just to try and convince you I'm
> not proposing things just for the sake of it :-)
> 1) no downsides: This is an optional feature, so if you don't do
> anything you are not affected. If you prefer rc.conf and its
> simplicity to whatever benefits you get from the new format, then you
> are free to stick with it. Indeed, even if you were to move to
> systemd, setting the hostname++ in rc.conf would still work (this was
> one of my first patches to systemd).
> 2) interoptability: I have seen patches appearing in the gnome
> repository adding support for the systemd-style config files,  and we
> can only hope that other third-party projects will follow. In my
> opinion it would be nice to be able to tell users that, if they want,
> they can move to the new format and get these features for free. The
> alternative would be to also add support for rc.conf to the relevant
> third-party project, but due to rc.conf being a bash script, this is
> not so simple (if we want to do it properly). To parse rc.conf, your
> app needs to use a bash interpreter (as rc.conf could contain any bash
> code), and writing to rc.conf can only be done correctly and without
> creating a mess if you make assumptions about it's structure (e.g.
> that it only contains assignments, and no conditionals / loops /
> sourcing...).
> 3) cross-distro compatibility: imho it is a real benefit to everyone
> doing the trivial things in the same way (or at least it being
> possible to do them in the same way). I guess this would be
> appreciated by admins who have to deal with different distros on
> different machines. Eventually it would also make non-distro-specific
> guides, books, tutorials, etc simpler.
> What do you think? Still NACK?

You had me at #1...    My main concerns is a slippery slope where this 
extra file gets introduced as optional now, but after a while it becomes 
accepted as the default way to configure stuff and then more changes are 
made so that rc.conf stops working.  Cross-distro compatibility etc is 
all good, but remember there are reasons for different distros and we 
should not lose what makes Arch unique.

Anyway, my voice of descent is rather weak given I have little 
understanding of the whole start-up process (push button, magic occurs, 
login prompt...).  And it is good to see this whole area being given the 
attention it deserves.  So in the end, I defer to whatever the people 
doing the work think is best.


More information about the arch-projects mailing list