Bart Smaalders wrote:
That would be cool, but unfortunately it's not a realistic answer -
there are just too many similar plug-in infrastructures to require
that they all be fixed before they can be used.
So it's better for each application to hack together it's own
mechanisms?
Not everybody has write access to the cron sources, nor does everybody
have the time or interest to hack them. My old group was 98% Java
programmers. If they want to have a cron job as part of their
application, their only practical choice is to hack together their own
mechanism, at least until somebody else fixes cron. (But remember cron
is far from unique here; after you fix cron there will still be
uncountable similar applications.)
If you want to modify system files as a result of installing or
de-installing a package, I think the right way to do this is via
the mechanism I described.
Absolutely. The people who own those system files should get right on
fixing their components to be packaging-friendly. What should the rest
of the world do in the meantime?
It sounds like the answer is to have the application squirrel away
some unpackaged files that will clean up and self-destruct on the next
reboot, or when invoked by this service-based mechanism.
Gack. Please don't do this.
So what are developers who do not have the time, experience, or access
required to fix cron to do to ensure that their cron jobs are removed
when the application is uninstalled?
If you have an application that has IPS packaged plugins, then it can
discover the missing or new plugins on next startup.
Yes. Here we're talking about an application that's plugging into
*other* applications' plugin mechanisms.
Though even for mechanisms controlled by the developer it's not always
trivial to rebuild the mechanisms to be packaging-friendly. Consider,
for instance, that the IPS team felt it necessary to build custom
mechanisms to support Solaris kernel configuration files. You could
have fixed the Solaris kernel so that it would dynamically assemble the
contents of those files, but that was too hard so you implemented
special mechanisms to solve that point problem. Most of the world
doesn't have that luxury.
If you're adding entries to crontab, etc, let's get those things
fixed as part of S11 development. We don't need to re-invent
scripting via proxy scripts.
Cron.
Sendmail.
Apache.
Termcap.
/etc/mailcap.
/etc/mime.types.
Solaris WBEM Services.
/etc/iu.ap.
/etc/dacf.conf.
/etc/format.dat.
/etc/system.
gconf.
logadm.
PAM.
Syslogd.
/etc/services.
RBAC.
That's all I could think of offhand and with a brief scan of /etc, but
I'm sure if I hunted around a bit I could find any number more - I
didn't even touch X, for instance.
Plugin support by adding a new entry to a file is a long-established
tradition. Yes, there are better ways and applications should move to
those better ways, but the people who need to plug in are often not the
people who are in a position to fix the architecture, and there are too
many such plug-in frameworks to just assert that they'll all get fixed
before anybody needs them.
A developer who is considering moving an application to IPS and who
encounters such a situation has three realistic options today:
1) Hack up a replacement for scripting.
2) Leave trash all over the system on uninstall.
3) Stop considering moving to IPS.
Which of those would you prefer?
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
