From owner-svn-ports-all@FreeBSD.ORG Wed Jul 16 11:35:54 2014 Return-Path: Delivered-To: svn-ports-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACC92D51; Wed, 16 Jul 2014 11:35:54 +0000 (UTC) Received: from h.highsecure.ru (mail6.highsecure.ru [IPv6:2a01:4f8:191:22a6::99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6769C2D54; Wed, 16 Jul 2014 11:35:54 +0000 (UTC) Received: from medway.cl.cam.ac.uk (medway.cl.cam.ac.uk [IPv6:2001:630:212:238:21c:c0ff:fe4b:2b85]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by h.highsecure.ru (Postfix) with ESMTPSA id 1274D30008B; Wed, 16 Jul 2014 13:34:25 +0200 (CEST) Message-ID: <53C6638E.6000801@FreeBSD.org> Date: Wed, 16 Jul 2014 12:35:42 +0100 From: Vsevolod Stakhov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alexey Dokuchaev Subject: Re: svn commit: r361646 - in head/net/samba36: . files References: <201407122229.s6CMTN42057554@svn.freebsd.org> <53C322A7.2090705@marino.st> <20140714003112.GA54756@mouf.net> <53C451FA.2020304@marino.st> <20140715170501.GA73101@FreeBSD.org> <53C5618F.2020104@FreeBSD.org> <20140716094453.GA53961@FreeBSD.org> <53C65677.8060603@FreeBSD.org> <20140716111328.GB82901@FreeBSD.org> In-Reply-To: <20140716111328.GB82901@FreeBSD.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-ports-head , "Timur I. Bakeyev" , Steve Wills , svn-ports-all , marino@freebsd.org, "ports-committers@freebsd.org" X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 11:35:54 -0000 On 16/07/14 12:13, Alexey Dokuchaev wrote: > On Wed, Jul 16, 2014 at 11:39:51AM +0100, Vsevolod Stakhov wrote: >> I'd like to ask a single question only: do you really think that the >> whole FreeBSD project should just fulfil your needs? That's nonsense: we >> should take care of *users* first. And believe me, they won't be happy >> if their upgrade is broken just because you use archaic hardware to >> build ports. > > It is broken not because of me or my hardware. And mind you, there are lots > of folks who build ports on not-so-superfast MIPS and ARMs; sparc64 are also > quite slow compared to modern x86, even not so archaic ones. > > Even on my superfast Q9550, where I care less for build times, I still would > like to avoid needless port rebuilds. > >>> Tell me, why on earth shall i bump revision for a typo fix in COMMENT or >>> pkg-message, www, maintainer change? Why do I have to waste time and CPU >>> cycles for rebuilding my otherwise perfectly fine packages? >> >> Fell free to suggest your set of fields. Unless we have released pkg 1.3 >> this set is a subject for discussions. > > I don't see why it cannot work the old way, just as described in PHB section > 5.2.2.1. That is, bump port revision when something is wrong with previous > package. Fixed typos or added license do not render previous packages wrong. > Ditto for staging, maintainership changes or other things that are not user- > noticeable. OMFG, it cannot work in the old way because we *do have* pkg and many users use pkg for their tasks. And you suggest to remove pkg support just because you don't want to rebuild the ports? That's awesome... >From the side of pkg we could just use portversion for everything but this assumes that *all* maintainers know how to bump portrevision. And that was lie over all the history of the ports. Indeed, if we define something like 'bump revision if something is wrong with a port' then we are in trouble, as different maintainers have different viewpoints about what is wrong and what is not. Hence, if you have more constructive suggestions than to throw out pkg I would appreciate to hear them. -- Vsevolod Stakhov