On Sat, 26 Dec 1998, Hubert Feyrer wrote:

> A more unique suffix than ".old" should be chosen here if this is
> automated. Users may have .old files flying around for themselves, and we
> should better not nuke their files away. Maybe something like ".oldpkg"
> would be better. 

I'm amenable to using an iterative means to do the renaming: use
.old1 if .old exists, .old2 if .old1 exists, etc., though this
exact scheme doesn't appeal to me because it reverses the digit
sense used in logfiles (lowest number is newest, highest is oldest).
I personally don't really feel like bothering to save the files at
all, since they're always available from the distribution sets,
but others seem to like this.

> This is a bit more complicated that this: Imagine we're upgrading a
> package (say sendmail), and do not update the config files. In that case,
> it's not guaranteed that the new package does work propoerly due to an old
> config file.

Right. In this case, the sysadmin has to be warned about this and
has to deal with the merge himself, since it also may not operate
`properly' (from the sysadmin's point of view) with the new config
files, either.

>  - make packages aware of which files actually are config files and thus
>    need some special handling
>  - install sample config files in $PREFIX/share/examples/<pkgname> as
>    noted in b) above, possibly moving aside old files/dirs.
>  - install example config files in place
>  - if a previous config files existed, back it up somewhere and tell the
>    system administrator (or whoever runs the pkg_add) to check things!
>    (Maybe even offer some aid via merge(1) or so)

Right. The only thing I don't see the need for is the backup of
the previous config (the one in /etc); the admin can do that himself
using whatever local backup procedures he uses. Backing up the
previous *example* config (in share/examples/<pkgname>), on the
other hand, I consider to be quite important, because diff or merge
is what you'd use there to figure out what changes you might need
to bring into your config files.

One thing I've still not really worked out is what to do on the
next upgrade, when you've got <pkgname> and <pkgname>.old in
share/examples. Delete the old? Insist the sysadmin delete it before
installing a new package? 

This seems to me a more general instance of the `how do you back
up a file' problem; it's different depending on the admin. Some
use .1, .2, .3, etc.; some use .old; some use ~; some use RCS.
I'm open to suggestions on how to deal with this issue.

> The implementation of this would be to add a "@conf" tag in front of all
> files in pkg/PLIST files, and make pkg_add do the right thing (as above).
> Furthermore, pkg_delete could also move the file aside.
> 
> [But that's probably something not belonging here into this proposal.
>  Comments still welcome :]

I think we should stick it in, so that we can get everything worked
out to everyone's satisfaction. Planning the whole shebang in
advance, rather than planning it piecemeal, can't hurt, I think.
(We can still implement piecemeal if we need to.)

> > 5. Daemons that start at boot time should have a start/stop script
> >    available....
> 
> Maybe also some "restart", causing the daemon to properly shutdown, free
> resources and restart (in case reloading isn't available or not wanted due
> to some reason).

Sounds reasonable enough to me. My long range plan for dealing with
such things would be to have a program that can act as a front end,
so you can just say `daemonctl named start', for example, and it
can take care of starting it. Eventually you can use this as a
building block in your rc dependency system.

cjs
--
Curt Sampson  <cjs@cynic.net>   604 801 5335   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org