From owner-freebsd-ports@FreeBSD.ORG Mon Mar 29 17:27:56 2010 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 59A5D1065674 for ; Mon, 29 Mar 2010 17:27:56 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id B5E4F8FC14 for ; Mon, 29 Mar 2010 17:27:55 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D0E1F5ACCB; Mon, 29 Mar 2010 19:27:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id CDE0E5ACC8; Mon, 29 Mar 2010 19:27:54 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id ADFCB5CEC5; Mon, 29 Mar 2010 19:27:54 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.1FP1) with ESMTP id 2010032919275343-30734 ; Mon, 29 Mar 2010 19:27:53 +0200 Received: by wep4035 (sSMTP sendmail emulation); Mon, 29 Mar 2010 19:27:53 +0200 Date: Mon, 29 Mar 2010 19:27:53 +0200 From: Alexey Shuvaev To: Ivan Voras Message-ID: <20100329172753.GB39715@wep4035.physik.uni-wuerzburg.de> References: MIME-Version: 1.0 In-Reply-To: Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.20 (2009-06-14) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.1FP1|January 05, 2010) at 03/29/2010 07:27:54 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.1FP1|January 05, 2010) at 03/29/2010 07:27:54 PM, Serialize complete at 03/29/2010 07:27:54 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-ports@freebsd.org Subject: Re: "stable" ports? 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: Mon, 29 Mar 2010 17:27:56 -0000 On Mon, Mar 29, 2010 at 05:57:04PM +0200, Ivan Voras wrote: > Hi, > > First of all, I'd like to have this particular discussion in the open > with ports developers and maintainers. So please - if you are a "simple" > user, without a port to maintain, you will be given another thread if > anything comes out as a result from this discussion. > To start with, the number of ports I maintain is not large at all, and all of them are mostly "dark corners" never used. > There is a discussion[*] currently in The Forbidden Palace about the > possibility (it's just that - a discussion of viability) of having a > "stable" ports branch which would in the future as a consequence enable > building binary packages and deploying them in the way of Linux's "apt" > and "yum" tools. > > One way to do it, my proposal, would be to maintain a stable "overlay" > of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x), > containing ports deemed "important" for some reason. > What is the criteria which port version goes into particular branch? That is, which versions of, say, gtk will have 6.x, 7.x and 8.x? Is it supposed to be what was available at the time when the branch was out? If this is the case, 6.x branch will have pretty outdated "heavy infrastructure" ports (like gnome/kde libs, see below). What if the supported lifetime of the port upstream is less than supported lifetime of FreeBSD branch? Who will backport at least security fixes to the port? > Some more potential properties: > > * Ports in the stable branch/overlay would be maintained with more > rigorous checking. > Are the current ports not already rigorously tested? :) > * Updates which break shared libraries would not be allowed within such > a branch/overlay (i.e. no updating gnome 2.xx to 2.x(x+1), libpng, > libjpeg, xorg). > On the one side who will maintain such a beasts like outdated version of xorg??? On the other side, if all major ports are "frozen" what is left to be updated? In other words what is the difference between proposed "stable" ports branch and a static snapshot? > * Binary packages for a whole X.Y branch would be built on X.0 (e.g. on > 7.0 for all 7.x branches). > Could not this be done already with the current ports? > This is obviously pretty fuzzy - rules would need to be specifically > made later. > > The biggest problem would seem to be the burden this would have on ports > developers vs the gains that could be gotten from this system. > > In some cases the burdens are obvious - the maintainer(s) would need to > e.g. maintain three versions of the ports - a random example would be > e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be > keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future > (CURRENT/9.x) branch. > > Some of the benefits are also obvious. The scheme would allow faster and > more convenient updating of the system, without breakage of shlibs > within a branch. > > Within all this, I think one point is important: there should be no > inventing of wheels or pioneering work on this. Much the same concepts > are already proven to work with Linux systems (stable package branches, > apt and yum), so this is not very much unknown territory. Here not be > dragons :) > I have not used Linux myself in the last 6 years, so I'm not very confident with all these 'apt', 'yum' and co, however I have 2 Ubuntu installations not far from me. Well, as tools they (apt, ...) may be quite good, but I remember the too early update to firefox3 (which crashed every few minutes and that was an official gnome browser!) and the problems with intel video card (hard freeze of the system) after upgrade to the new Xorg. So, the tools alone do not solve that many problems... > I consider this just an opinion-collecting thread: Would you, as a > maintainer / developer, be interested in something like this, and why? > Weighting these all, I would say no. There is already enough fun keeping ports working on CURRENT. And see below. > [*] the discussion was started unexpectedly following my post bringing > http://blog.hagander.net/archives/167-PostgreSQL-infrastructure-updates.html > to attention. > Quoting: "... that will ensure that all our machines look the same way. This also plugs into our monitoring systems very well, making applying (security) updates across the many machines much easier. ..." It's a pity that pgsql devs are not familiar with ports-mgmt/tinderbox... Looks like it is exactly what they need. Maybe the README from tinderbox deserves the place in the handbook ("Preparing packages in corporate environment" or something similar)? Compiling the set of possibly customized (patched) packages for further deployment on a large number of machines is an easy task when using tinderbox. Back on topic, would not it be better to provide "official packages for upgrades" built from some chosen snapshots of the ports tree? Then some community (portmgr?) would shape the flow of updates to the tree, blocking the "sweeping changes" (and allowing all others?) during preparation of the "snapshot points"? Something similar is already done during releases. Updating one ports while holding the others sounds more like repository manipulation rather than a real maintainance of different branches. In some cases (when really needed?) there are already different variants of the same port (port / portXY / port-devel). Alexey.