From owner-freebsd-ports@FreeBSD.ORG Fri Aug 1 06:43:08 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 89DEC1065675 for ; Fri, 1 Aug 2008 06:43:08 +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 3AC618FC1B for ; Fri, 1 Aug 2008 06:43:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 11212 invoked by uid 399); 1 Aug 2008 06:43:08 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Aug 2008 06:43:08 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4892B07A.60702@FreeBSD.org> Date: Thu, 31 Jul 2008 23:43:06 -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> <4892022F.1080009@FreeBSD.org> <9bbcef730807311438m45802827y91c7bb7366406af6@mail.gmail.com> In-Reply-To: <9bbcef730807311438m45802827y91c7bb7366406af6@mail.gmail.com> 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: Fri, 01 Aug 2008 06:43:08 -0000 Ivan Voras wrote: > 2008/7/31 Doug Barton : > >> 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. > > No, portupgrade isn't mandatory, and it probably never will be > because of ruby. It's only the most widely used and I think that > any scheme that adds or changes to the behaviour of the ports > infrastructure must also include portupgrade to be useful to the > most users. At first glance these two statements seem contradictory, but I think what you meant in the second sentence is that for the new system to work portupgrade has to have support for it before it is rolled out. If so, then I agree with you and would only add that authors of other ports management tools should be given adequate notice of the plans as well. > Note that, if I implement pkg_trans, any tool that doesn't know > about it will, at best, generate useless single-package > transactions (and at worst break the system, but I'll try hard to > avoid this). Thus my concern. :) >> 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. > > Port N then won't install D2 as it already exists. Right, but D2 is still part of the transaction for N. If I roll back M but leave N installed, then roll back N, D2 should be removed (assuming for this example that D2 is not relevant to any other port). > The user can rollback [N], then rollback [M+D1+D2+D3]. Trying to > roll back back [M+D1+D2+D3] before [N] will show the user a message > about dependencies. I seriously doubt that users would put up with that. Trying to think as a user here, I certainly would not want to be told that in order to remove a port that I don't want I first have to remove one that I do. But perhaps I'm misunderstanding you again. Doug -- This .signature sanitized for your protection