From owner-freebsd-ports@FreeBSD.ORG Thu Jul 31 18:19:29 2008 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE36E106566C for ; Thu, 31 Jul 2008 18:19:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 812A68FC0A for ; Thu, 31 Jul 2008 18:19:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 1688 invoked by uid 399); 31 Jul 2008 18:19:28 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Jul 2008 18:19:28 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4892022F.1080009@FreeBSD.org> Date: Thu, 31 Jul 2008 11:19:27 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Ivan Voras References: <489144B5.4030101@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: Call for comments - pkg_trans X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2008 18:19:29 -0000 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