From owner-freebsd-ports@FreeBSD.ORG Thu Jul 31 22:06:06 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 03AAF1065673 for ; Thu, 31 Jul 2008 22:06:06 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id C4F478FC26 for ; Thu, 31 Jul 2008 22:06:05 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1023965rvf.43 for ; Thu, 31 Jul 2008 15:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=X6oEPPxWC32OxTV2YI1dA+T88yvCDC6lZmfUmazaBts=; b=QU0dz4czsDG8kbmG52ox/SaXhBffV+QA6QkSgifrxdqnsmxRuHkbWDdQOlNcMO3Wvz pBLZoPy650kA+QuZqMLP3CkuTS+AfTopRdoR6/4qEU0cRDQLLWbF23/43q0VMe4bFdT2 xpUAPG/KlAKM5GT07ueGKPYEbVDGcJCpSXHNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=WdvS87aDv+KerwnZtNigkWMboQR03UeyN5JZfBByMItU2EY9vzAx6be3sLJO6bNU6v Q4KIKNC4VJMS6jFerTUvztPyaRGDBipojLPLj7tNtZ/N4LsuH6CNVNK57ipPLaXADltx uZgj6j+ps+LPW/fW9JDX/9U8A2In7HQ1ZE2Y4= Received: by 10.141.133.14 with SMTP id k14mr5552422rvn.127.1217540301528; Thu, 31 Jul 2008 14:38:21 -0700 (PDT) Received: by 10.141.159.2 with HTTP; Thu, 31 Jul 2008 14:38:21 -0700 (PDT) Message-ID: <9bbcef730807311438m45802827y91c7bb7366406af6@mail.gmail.com> Date: Thu, 31 Jul 2008 23:38:21 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Doug Barton" In-Reply-To: <4892022F.1080009@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <489144B5.4030101@FreeBSD.org> <4892022F.1080009@FreeBSD.org> X-Google-Sender-Auth: fd78c68abd70ee1d 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 22:06:06 -0000 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. 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). > 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. 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. > 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. A good "-f" (force) command will solve many issues :)