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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
