Nicolas Williams wrote:
> On Wed, Aug 27, 2008 at 02:27:58PM -0700, Jordan Brown wrote:
>> Interaction with SMF might well address the possible need for removal
>> vetoes for services-running. Whether it completely addresses the need
>> for preremove is less clear to me. For instance, when you go to
>> uninstall Adobe Reader, one of the things that should happen before you
>> actually remove the executable is to remove the entry in /etc/mailcap
>> that refers to it. (Granted, race conditions still cause problems.
>
> What's wrong with a single generic service for things like mailcap
> updates?
I'm not sure exactly what you mean. I can think of three possibilities:
1) A single generic service that somehow manages all sorts of files
with entries that need to be added and removed. Hmm. My initial
thought is that that's ludicrous because of all of the variations, but
as I think about it more maybe it isn't. Have a service that
concatenates all of the files in a directory into a single file, and
then optionally executes a command to refresh the affected application.
Either have multiple instances of this service, one per file to be
maintained, or have the service itself have a mechanism for subscribing
a {directory,file,cmd} tuple. Of course, you couldn't let people
directly edit the file being managed, and that'd be a compatibility problem.
2) A service for /etc/mailcap, and another service for /etc/termcap,
and another service for X fonts.dir, and another for /etc/profile, and
another for ... That seems to be the direction that IPS is heading, but
(a) that's a lot of services, and (b) it's entirely dependent on the
provider of the file to create the service - the Adobe Reader wad would
be out of place trying to create such a service for /etc/mailcap.
3) A service for Adobe Reader's attachment to /etc/mailcap. Starting
the service adds the entry to /etc/mailcap; stopping the service removes
it. Kind of cool in that it provides an abstracted way to enable and
disable the file type association, but as I said rather a stretch. Has
the advantage that it could all be done as part of Adobe Reader, though.
> pkg removal -> drop a note where that service will find it and
> ping the service. Better: pkg removal -> ping that service and let it
> discover what changed.
Who is going to create this service for /etc/mailcap, and
/etc/inet/services, and /etc/termcap, and /etc/mail/aliases, and root's
crontab, and /etc/dacf.conf, and /etc/format.dat, and on and on and on?
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
