Call for comments - pkg_trans
ivoras at freebsd.org
Thu Jul 31 22:06:06 UTC 2008
2008/7/31 Doug Barton <dougb at freebsd.org>:
> 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
> 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 :)
More information about the freebsd-ports