Call for comments - pkg_trans

[Doug Barton]

Ivan Voras wrote:
> Hi,
> 
> I apologize in advance if what I'm trying to do seems stupid or it has 
> already existed since the Dawn of Time (i.e. when McKusick was in 
> diapers) but I'd like your comments on this idea:
> 
> http://wiki.freebsd.org/IvanVoras/PkgTransProposal
> 
> I can write the pkg_trans utility and modify the C utilities (pkg_add, 
> pkg_delete, if they're sane) but I can't do makefiles and ruby, so if 
> this is to work, I'll need some help :)

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 
things it does now already are to save binary packages before running 
pkg_delete, and it has the ability to "roll back" installation of ports 
you no longer want, along with all dependencies related to those ports 
that become obsolete. Take a look at the -e and -s options for the 
latter, and the -b and -g options for the former. By default portmaster 
saves the backup packages until the current round of updates is done, 
then if the user hasn't specified the -b option they get deleted before 
portmaster exits.

In terms of the rest of your proposal, off the top of my head the 
transaction IDs should probably be saved in /var/db/ports. I need to 
think harder about what format .... you could probably have a 
/var/db/ports/trans/ and then save the logs of the transactions as 
individual files by transaction ID. The wheels are spinning in my mind 
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.

As I said though, portmaster already has the capability to do two things 
you say you want to support, albeit the "rollback" operation would have 
to be done manually. I think it would be pretty simple to add support 
for an "undo" feature when it comes to upgrading something in place 
and/or deleting existing stuff as long as you don't expect the ability 
to undo that particular transaction to last longer than the time period 
until you modify something that was part of it. I think "undo" for a new 
installation is harder for the reasons I mentioned above, but the good 
news is that it's already possible to do most of that just using the 
existing ports infrastructure.

hth,

Doug

-- 

     This .signature sanitized for your protection