Patching config files (or not)

[Jos Vos]

Hi,

Should configs files of a package be patched to have settings that
make it work more or less out of the box (as far as possible, some
setting like DB access etc. just can't be filled in in advance)?

I came across a package that defines to use "nogroup" in its config
file as effective group (Fedora has no "nogroup", but has group
"nobody")
and defines to put a pid file in /var/run (which fails, as it appears to
do that as nobody/nobody when running).

Should this config file have been patched to use "nobody" as group and
should the package (for example) include a package-specific directory
below /var/run to put its own pid file in (and patch the config file
to use this directory for pid files)?

Just wondering if it is worth filing bugs against this package
because of the above (easy to solve) issues...

Cheers,

--
--    Jos Vos <jos(a)xos.nl&gt;
--    X/OS Experts in Open Systems BV   |   Phone: [phone]
--    Amsterdam, The Netherlands        |     Fax: [phone]

[Stephen Gallagher]

On Fri, 2011-08-12 at 18:50 +0200, Jos Vos wrote:
>  Hi,
>  
>  Should configs files of a package be patched to have settings that
>  make it work more or less out of the box (as far as possible, some
>  setting like DB access etc. just can't be filled in in advance)?
>  
>  I came across a package that defines to use "nogroup" in its config
>  file as effective group (Fedora has no "nogroup", but has group
> "nobody")
>  and defines to put a pid file in /var/run (which fails, as it appears to
>  do that as nobody/nobody when running).
>  
>  Should this config file have been patched to use "nobody" as group and
>  should the package (for example) include a package-specific directory
>  below /var/run to put its own pid file in (and patch the config file
>  to use this directory for pid files)?
>  
>  Just wondering if it is worth filing bugs against this package
>  because of the above (easy to solve) issues... 

I think the problem is twofold: if the package as shipped requires the
existence of a particular group, it's the responsibility of the packager
to ensure that the group exists on the system. So as part of the install
scripts (probably in %pre) you need to create the group on the system.

That said, it would be best to work with upstream to add a configure
option to select the group most appropriate for each platform.

[Matej Cepl]

Dne 12.8.2011 18:50, Jos Vos napsal(a):
>  Should configs files of a package be patched to have settings that
>  make it work more or less out of the box (as far as possible, some
>  setting like DB access etc. just can't be filled in in advance)? 
There are many caveats to this answer, but I think generally speaking 
the answer is “Yes”. Isn't it a whole purpose of package maintenance to 
integrate all those various programs into one distribution which works 
together?

Matěj

[Tomas Mraz]

On Fri, 2011-08-12 at 18:50 +0200, Jos Vos wrote: 
>  Hi,
>  
>  Should configs files of a package be patched to have settings that
>  make it work more or less out of the box (as far as possible, some
>  setting like DB access etc. just can't be filled in in advance)? 
If possible and does not really need individual configuration by a
system administrator, yes.

>  I came across a package that defines to use "nogroup" in
> its config
>  file as effective group (Fedora has no "nogroup", but has group
> "nobody")
>  and defines to put a pid file in /var/run (which fails, as it appears to
>  do that as nobody/nobody when running).
>  
>  Should this config file have been patched to use "nobody" as group and
>  should the package (for example) include a package-specific directory
>  below /var/run to put its own pid file in (and patch the config file
>  to use this directory for pid files)? 
It is generally insecure to share groups/uids between different system
daemons.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb