Call for comments - pkg_trans

Doug Barton dougb at
Thu Jul 31 18:19:29 UTC 2008

Ivan Voras wrote:
> Doug Barton wrote:
>> You have some very interesting ideas there. Not that I want to 
>> dissuade you in any way from doing this, but I would like to point out 
>> that portmaster already does some of what you're suggesting and it 
>> could fairly easily be modified to do just about all the rest of it. 
>> The two 
> I really want the standard ways of installing and upgrading packages 
> (make install, portinstall) to support those features.

type portinstall
bash: type: portinstall: not found

Hmmmm, I guess that's not so standard after all. :)

Seriously though, I don't want to get into a ports-tool debate. I was 
explicit in saying that I don't want to dissuade you from adding this 
support to the pkg_* tools. My point is that there are already ways to 
do some of what you're suggesting, and you may be able to leverage that.

>> right now about how this could get hairy down the road when you 
>> install a bunch of stuff as dependencies for fooport, then you start 
>> doing upgrades on the individual dependencies the log of the 
>> transaction quickly becomes less valuable. Some thought would have to 
>> be given to exactly what the goals are, how long those logs should be 
>> valid/useful, etc.
> Yes, rolling back old transactions, after individual packages in them 
> have been updated will be a problem. I see a way out of it if only 
> portupgrade is used for the upgrading so information exists about which 
> package is upgraded by which.

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.

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.

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.

To continue brainstorming, it might be useful to combine the strategy 
that portmaster uses with a variation of your idea. If you take a look 
at the categories portmaster uses to define ports (roots, trunks, 
branches, and leaves) the first is a port with no dependencies, up or 
down; and the last is a port that has dependencies but is not depended 
on. If the transaction log only recorded the root and leaf ports those 
could easily be rolled back together and then you could use the logic 
from portmaster's -s option to handle deleting stale dependencies. 
This would still require some care to maintain since ports that are 
roots or leaves today might become trunks or branches tomorrow, but it 
would require less maintenance than trying to keep track of everything.




     This .signature sanitized for your protection

More information about the freebsd-ports mailing list