Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jun 2007 21:45:40 +0200
From:      Alex Dupre <ale@FreeBSD.org>
To:        freebsd-ports@freebsd.org
Subject:   Re: make update broken
Message-ID:  <46704964.7000205@FreeBSD.org>
In-Reply-To: <20070613173159.GK90672@droso.net>
References:  <466279CC.8030200@gmx.de> <4663D0B9.4000602@FreeBSD.org>	<46701E0B.6010804@gmx.de> <46701FAD.7020204@FreeBSD.org> <20070613173159.GK90672@droso.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Erwin Lansing wrote:
> As I described earlier, SUP_UPDATE, CVS_UPDATE and PORTSNAP_UPDATE are
> mutually exclusive and cannot be used at the same time.  That it worked
> before was an artifact which has been fixed.  That is doesn't work
> anymore means the designed behaviour finally has been fixed and not
> broken :-)

As I said before, this is a non-sense: portsnap cannot be used to update
src, so it shouldn't prevent to use sup or cvs for such job. I don't
know who decided such mutually exclusive behavior, but actually is a
(wrong) priority behavior, so the design is still flawed in that sense
(if you define SUP_UPDATE and CVS_UPDATE you will use cvs, if you define
SUP_UPDATE and PORTSNAP_UPDATE you will get an error).

I vote for the enhanced priority behavior:

        src                   ports

SUP_UPDATE + SUPFILE      PORTSNAP_UPDATE
CVS_UPDATE                SUP_UPDATE + PORTSSUPFILE
                          CVS_UPDATE

> Your patch reintroduces PORTSNAP_UPDATE with a new meaning.

Previous meaning, not new. Where is defined the official PORTSNAP_UPDATE
meaning?

> While I
> dislike this workaround for an unsupported configuration, it may be
> needed for backwards compatability.  Please send-pr your patch, but
> please also add documentation of the new meaning of PORTSNAP_UPDATE.

I'll do it.

--
Alex Dupre



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46704964.7000205>