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.
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]"