On Sun, Mar 27, 2011 at 01:21:12PM -0700, Jordan K. Hubbard wrote: > If you're willing to "sin" from a security standpoint by allowing arbitrary > @exec/@unexec operations to occur, then you can just skip the tailoring and > leave things open-ended (or defined by policy) since you have no realistic > hope of controlling what packages do if that's your sin of choice. Of > course, If you think you can actually express the full set of installation > operations as a set of properties which folks who are used to "make install" > can also realistically cope with then you're a smarter / better man than > myself and I wish you all the luck in the world, seriously, because I will be > observing with great interest! :-)
I'm equally skeptical that it's possible to have a useful package system where packages don't have the ability to run arbitrary shell commands post-install. All of the major package formats I'm familiar with (dpkg and rpm come to mind) have this capability, and I think applications need this flexibility. By my count, we have 463 ports with (pre|post)-(install|activate|deactivate) hooks. Many of these are ui_msgs that ought to be replaced with notes, or other things that could fit into a restricted set of operations. But it also seems very common for packages to need to update caches or indexes using a specific tool like texhash or gtk-update-icon-cache, and hardcoding a list of those into the package manager does not seem like a winning idea. For me, that count also makes an argument in favor of a package format that includes and evaluates the TCL portfile: editing that many ports to put the post-activate hooks in some new format is a non-trivial task. Certainly not insurmountable, but given the desire to see binary packages sooner rather than later, I'd rather not put any more obstacles in the way. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
