Okay, so basically we have solutions X and Y. X = having a small pre-defined set of operations in post-install (with friends) without full environment Y = having full TCL (with ports) environment
Using X is good because it keeps down the size of the binary installing command as it doesn't need the dependencies. Using Y is good because you can do whatever you want. Nether solution is optimal by itself. How about this: We use both X and Y. We have atom operations for common tasks and do not ship it with ports. However, for ports that use some sub-standard strange operations in the post-install section, will have to have an extra dependency to the ports environment and/or a TCL interpreter. Then size will be held down for 99.99% of all ports, and for the remaining 0.01% of ports that have post-install scripts with strange stuff, we simply install whatever we need for the post-install (not necessarily whole environment). There are three main ideas here: 1) Optimizing for the most common case, without losing the ability to handle the less common cases. 2) Combining the benefits of the two solutions. 3) Transferring the headache of deciding whether ports environment should be shipped or not only for the small post-script, to the maintainers. So basically, even the port file itself will then have dependencies, not only its binary. - Fisk Mar 26, 2011 kl. 8:05 PM skrev Jordan K. Hubbard: > > I realize that this is a little long, but I figured the least I could do to > atone for the lack of binary packages being in MacPorts from day 1 was to > describe the problem space in as much detail as I could recall... HTH! > > - Jordan > _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
