Call for comments - pkg_trans

[Ivan Voras]

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
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 :)