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
