On 16 Jul 2014, at 08:44, Sebastian Luna Valero <[log in to unmask]> wrote:

> 
> Could you please explain why that is not the way to go?
> 
> 
> 

Well in the list below we have
desktop tweaks which is moot by upstream
password single user which is moot by upstream

This leaves 2:
* serial console: which is more cleanly performed by doing a serial console install. As already discussed.
* no colour ls: this package %post renames /etc/profile.d/colorls.[sh|csh] files so they become inactive.
This would be better performed in a kickstart %post although see next paragraph.

> What alternatives do you recommend?


In my opinion all of these small tweaks are really in the realm of systems administration not distribution packaging.
In my opinion the best way to administer systems is via a configuration management tool like cfengine3 or puppet  or quattor or $insert_conf_tool_of_choice, failing that use a kickstart file to impose your will on systems.

Helping part-time/amateur system administrators do things in a simple and effective and educational manner is a fantastic goal. I worry that tweek packages do not achieve this aim as they hide “magic” and so are not educational. If the aim is to provide the part-time admin a quick line to add to a kickstart file then equally effective lines added to the kickstart %post rather than the %packges section would achieve the same aim AND be more educational. 


Also if we accept the need for tweek packages where do we stop? The whole strength of a Linux/Unix/Posix type system is its near infinite configurability. This means there will enevitably disagreements on the distro default configuration. If we are serious about tweaks packages being the way the distro caters for all possible configuration options then we will end up with more tweak packages than there are normal packages. And thus I argue that we should dispense with tweak packages altogether accept the distro has one default configuration that will not satisfy everyone and accept that system configuration is better implemented as a configuration management system rather than a packaging system. Again this is the Unix principal at work: one tool for one job and do it well.

Anyway those are my thoughts.


Alex Owen


 

> Best regards,
> Sebastian.
> 
> 
> 
> 2014-07-16 8:24 GMT+01:00 Alex Owen <[log in to unmask]>:
> On 9 Jul 2014, at 18:58, Orion Poplawski <[log in to unmask]> wrote:
> 
> > On 07/07/2014 10:07 AM, Pat Riehecky wrote:
> >> For SL6 we include the following 'tweak' rpms:
> >>
> >> SL_desktop_tweaks
> >> SL_enable_serialconsole-1152
> >> SL_enable_serialconsole-192
> >> SL_enable_serialconsole-384
> >> SL_enable_serialconsole
> >> SL_enable_serialconsole-96
> >> SL_no_colorls
> >> SL_password_for_singleuser
> >>
> >>
> >> The 'SL_desktop_tweaks' added a terminal to the menu bar, in SL7 this is
> >> already done by upstream.
> >>
> >> The 'SL_password_for_singleuser' required the root password for single user
> >> mode, in SL7 this is already done by upstream.
> >>
> >> This leaves 'SL_enable_serialconsole' and 'SL_no_colorls'.
> >>
> >>
> >> With SL7 the terminal seems to be very good a detecting support for the ASCII
> >> controls which set the colors.  Is this still something the community wants?
> >>
> >>
> >> With SL7 the serial consoles are very easy to setup.  Simply add:
> >>
> >> GRUB_SERIAL_COMMAND='serial --speed=9600 --unit=0'
> >> GRUB_TERMINAL_OUTPUT="$GRUB_TERMINAL_OUTPUT serial"
> >> GRUB_TERMINAL_INPUT="$GRUB_TERMINAL_INPUT serial"
> >> GRUB_TERMINAL="$GRUB_TERMINAL serial"
> >> GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX console=tty0 console=/dev/ttyS0,9600"
> >>
> >> to /etc/sysconfig/grub
> >>
> >> Anaconda (the installer) does this for you automatically if the serial options
> >> are set with kickstart.
> >>
> >> What are the various feelings here?  Make these rpms, don't make them?
> >>
> >> Pat
> >>
> >>
> >
> > Personally, never heard of them, and generally configuration by rpm installation seems like not the right way to go.  But I'm a small user…
> >
> 
> I concur that configuration by tweak packages is not a clean way to configure machines.
> For what it is worth Debian Policy prohibits one package from changing the configuration files of another package.
> The sound reasoning behind the Debain Policy would, in my opinion, also apply to Scientific Linux.
> 
> Regards
> Alex Owen
> 
> —
> https://github.com/raowen/conlog - Open Source IPMI Console Server and Logger
>