you apply the various defaults (global and group) to these accounts. If you only create new accounts using Linuxconf, then you do not need to use this.
There were 2 issues with packaging. The first is that my RPM is built to install on several distribution and it was confused on 6.0. It was installing Linuxconf on 6.0 the same way it was installing on Red-Hat 4.x. Problem.
The second problem made the first much more ... visible, to say the least. In Red Hat Linuxconf 1.14r4, they did a correct enhancement to the RPM. They simply defined /etc/conf.linuxconf as a configuration file. They did it properly, using the noreplace feature.
Unfortunately, my own RPM do not do this. So when you upgrade to say 1.15r3, rpm do the following:
So after the upgrade to 1.15r3, you end up with no /etc/conf.linuxconf. If you rename /etc/conf.linuxconf.rpmsave to /etc/conf.linuxconf, things may go better. Failure to do that cause Linuxconf to fail (segfault). Not good.
1.16 now include this config file directive, so upgrading from original redhat 1.14r4 package will go well. Upgrading from my own older package will produce a warning that a the file /etc/conf.linuxconf.rpmnew was created. Rpm does this because it see that the previous Linuxconf package did not have a /etc/conf.linuxconf file, but the new one has one. The noreplace directive tells rpm to keep the current one in place. It creates the rpmnew version to show you that a new file was added to the package, but could not replace an old file on the system.
Anyway, sorry for a long explanation. What does this means to all you rpm users around, and non-redhat rpm users. It means that
Note that this downgrade limitation (problem) will cure all by itself. the problem arises when going from a package which miss and RPM directive about /etc/conf.linuxconf. So downgrading from 1.16r4 to 1.16r3 won't be a problem.
Sorry, I did not find a way out of this. I hope I am not scaring you too much.