Subject: Packages touching /etc/services
To: None <tech-pkg@NetBSD.org>
From: Johnny C. Lam <jlam@pkgsrc.org>
List: tech-pkg
Date: 06/20/2006 01:56:56
Looking through pkgsrc, I see that some packages edit the /etc/services
file directly in the INSTALL script, but don't attempt to clean up
after themselves in a DEINSTALL action:
inputmethod/canna-server/INSTALL
inputmethod/skkinput/INSTALL
inputmethod/skkserv/INSTALL
I think this behavior is a bug. I believe the correct semantics for
a package is that if one installs and deinstalls it with no intervening
steps, then it should be as if the system never changed state (think
of the bulk build machines where packages are often added and removed
automatically). The INSTALL and DEINSTALL scripts generated by the
pkginstall framework are carefully written to follow these semantics.
In this case where packages directly edit /etc/services, there are two
options:
(1) Remove the added entries on package deletion, similar to what is
currently done with /etc/shells.
(2) Inform the user in a MESSAGE file that the appropriate entries
should be added to the /etc/services database, e.g.
mail/cyrus-imapd and sysutils/cfengine2.
If we decide to do option (1), then we should add it as an action to
the pkginstall framework so that we have one implementation of this
and we don't have to rely on each package to come up with its own way
to do it. Doing option (2) is quite easy and is what many packages
in pkgsrc already do.
Personally, I like option (1) because it means more "grunt work" is
handled automatically for the admin, and the pkginstall action would
output something to indicate that services were being added to
/etc/services, e.g.
===================================================================
Adding services for skkserv-3.9.4nb4 to /etc/services:
skkserv 1178/tcp
===================================================================
and the following line would be automatically added to (and upon
deinstallation, removed from) /etc/services:
skkserv 1178/tcp # skkserv-3.9.4nb4
If we do go with option (1), then many packages that currently do the
equivalent of option (2) should be modified to take advantage of the
new pkginstall action.
Is there a consensus on how to deal with these packages? Do other
folks consider the current behavior to be a bug?
Cheers,
-- Johnny Lam <jlam@pkgsrc.org>