2008/7/31 Doug Barton <[EMAIL PROTECTED]>: > As I'm sure you can imagine, I would not regard any solution that says > "portupgrade is mandatory" very favorably, and I don't think I'd be alone > there. What you need to be doing here is to define the API so that whatever > tool(s) the user chooses can interact with the system.
No, portupgrade isn't mandatory, and it probably never will be because of ruby. It's only the most widely used and I think that any scheme that adds or changes to the behaviour of the ports infrastructure must also include portupgrade to be useful to the most users. Note that, if I implement pkg_trans, any tool that doesn't know about it will, at best, generate useless single-package transactions (and at worst break the system, but I'll try hard to avoid this). > BTW, I thought of another problem scenario. The user installs port M, and it > brings dependencies D1, D2, and D3. Then the user installs port N which also > has port D2 as a dependency. Port N then won't install D2 as it already exists. The user can rollback [N], then rollback [M+D1+D2+D3]. Trying to roll back back [M+D1+D2+D3] before [N] will show the user a message about dependencies. > The more I think about this idea of transactions as chunks of stuff that can > be reversed together the more I think that this facility probably needs to > be time-constrained, or at minimum have very good support for invalidating > itself to avoid problems with scenarios like the one I described above. A good "-f" (force) command will solve many issues :) _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
