[GSoC][Binaries support] Architecture

[Dan Ports]

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/