Date: Sat, 23 Aug 2014 09:46:46 +0200 From: Matthias Andree <mandree@FreeBSD.org> To: koobs@FreeBSD.org, Bryan Drewery <bdrewery@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: <53F846E6.6000307@FreeBSD.org> In-Reply-To: <53F62AB5.6060802@FreeBSD.org> References: <201408211556.s7LFuE0p041046@svn.freebsd.org> <53F61E42.4050104@FreeBSD.org> <53F6267E.9020909@FreeBSD.org> <53F62802.3030006@FreeBSD.org> <53F62AB5.6060802@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 21.08.2014 um 19:21 schrieb Kubilay Kocak: > 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. I wonder if an "annotated list" of versions would help the pkg solver handle these; if the metadata for a new package lists "Obsoletes: blah<3.0" then the solver would automatically remove blah<3.0. I haven't investigated how far the automatic solving in pkg works for such situations especially if you have the version part of the package name as in py27-* and py34-*, or db48 vs. db6. Basically it is a question if there are alternative versions to choose from on one hand, or on the other hand there is a clear (to the tool, anyways) upgrade path for a package that has gone away, like db43 to db5.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53F846E6.6000307>