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

[Seblu]

On Fri, Oct 28, 2011 at 2:57 AM, Allan McRae <allan at archlinux.org> wrote:
> 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.
>

I agree with Dan and Allan about the feeling that rc.conf become less
and less the central point of configuration.

But to have a complete hostname configuration, we have to take in
consideration, in our current archlinux setups, we needs to edit
/etc/rc.conf et /etc/hosts to have a right "hostname", "hostname -f"
and "domainname".
So i'm hesistant about hostname setting because it already need an
external file to be correctly setup.

About locale.conf, imho  the bug report was closed too quickly, the
current solution doesn't correctly adress the issue.
Inheritance of locales should not be done by a login shell but by
process granting access (by example pam). This would fix issues with
*dm started by inittab.
-- 
Sébastien Luttringer
www.seblu.net