Date: Fri, 22 Aug 2014 03:21:57 +1000 From: Kubilay Kocak <koobs@FreeBSD.org> To: Bryan Drewery <bdrewery@FreeBSD.org>, Matthias Andree <mandree@FreeBSD.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r365566 - head/Tools/scripts Message-ID: <53F62AB5.6060802@FreeBSD.org> In-Reply-To: <53F62802.3030006@FreeBSD.org> References: <201408211556.s7LFuE0p041046@svn.freebsd.org> <53F61E42.4050104@FreeBSD.org> <53F6267E.9020909@FreeBSD.org> <53F62802.3030006@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22/08/2014 3:10 AM, Bryan Drewery wrote: > On 8/21/2014 12:03 PM, Matthias Andree wrote: >> Am 21.08.2014 um 18:28 schrieb Bryan Drewery: >>> On 8/21/2014 10:56 AM, Matthias Andree wrote: >>>> Author: mandree >>>> Date: Thu Aug 21 15:56:14 2014 >>>> New Revision: 365566 >>>> URL: http://svnweb.freebsd.org/changeset/ports/365566 >>>> QAT: https://qat.redports.org/buildarchive/r365566/ >>>> >>>> Log: >>>> Add a BerkeleyDB upgrade helper script in preparation of 4...4.7 removal. >>> >>> Thanks for making things simpler. >>> >>> <joke> We now have a script to run another script that was made to make >>> using ports simpler. >> >> The point is to abstract away the chaotic (miniscule input difference, >> major difference in result) differences along the various dimensions of >> port upgrading tools and local database management tools. >> >> I don't think a textual description for UPDATING would have been much >> shorter and the whole migration will look scary enough to users with the >> around-ten-step upgrade... >> >> And people WILL have multiple db4* versions on their typical system >> unless they manipulated /etc/make.conf. >> > > No no, I agree with it. It's nice for the users. We have other such > scripts too such as the perl-after-upgrade was IIRC. > > Actually I find it appalling we need to use a tool to use ports at all > and wish it was all self-contained with 1 official interface. > We probably could have used one of these in python@ for cleaning up setuptools (old) and distribute remnants that caused many issues for users as we chased upstream, even with good instructions in UPDATING (since we couldnt cover all cases) I wonder too, to what extent a relatively generic interface for these things might be possible. -- koobs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53F62AB5.6060802>