From owner-freebsd-ports@FreeBSD.ORG Tue Mar 30 07:18:20 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 60A551065670; Tue, 30 Mar 2010 07:18:20 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id F04C88FC22; Tue, 30 Mar 2010 07:18:19 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so648319qwe.7 for ; Tue, 30 Mar 2010 00:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=5uN1ETD5zDtS1rLGFpshMXrWPq1AWUFNxCJVUmDcgEA=; b=dPlkApym6V1vH1KY5lp86FYfqidjHp+p9LUMvuANT7bBbhzrVuuZxUqabmL6L0frGD qLc0T+sTlmpqWqpUB2fKMzQ/VZWJDX+TCYzX31CzoeyWB2uoyBEGcejO2TOv0W9Sh2tX S6bq3mu0L+iXI4Mg0Idpee5bltVo9SGRml3Oo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eLXIP3vturL1qhmd6hdIx5r28ynMmBT5JhSsWmHlbKkjNYmSe1Wstsh1GWilOoulEo yf1NNKnErKf5YOOQJEPR+3a5wfrP1//SBmplDvJzikusQpDGEst1/gtkLUCaKp2ovoMs Wc7K1yp5KxhWgGb+ZIs0B0DKD6wPfOKyC5JOE= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Tue, 30 Mar 2010 00:18:19 -0700 (PDT) In-Reply-To: References: <20100329172753.GB39715@wep4035.physik.uni-wuerzburg.de> Date: Tue, 30 Mar 2010 00:18:19 -0700 Received: by 10.229.227.83 with SMTP id iz19mr1323748qcb.44.1269933499099; Tue, 30 Mar 2010 00:18:19 -0700 (PDT) Message-ID: <7d6fde3d1003300018gf395446g703cd287c6265a76@mail.gmail.com> From: Garrett Cooper To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 30 Mar 2010 07:18:20 -0000 On Mon, Mar 29, 2010 at 11:35 AM, Ivan Voras wrote: > Alexey Shuvaev wrote: > >>> 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? > > I'd suggest that yes - keeping the current ports tree as-is as the > "unstable" "HEAD". > >> If this is the case, 6.x branch will have pretty outdated >> "heavy infrastructure" ports (like gnome/kde libs, see below). > > Yes. Exactly as with all other operating systems with long-term support and > binary packages. OTOH, users can always track HEAD as they do now. Only the > users who really need it would follow the "stagnating" branches. See ref: > Debian :) > > Also, nothing (for some values of "nothing") would stop people running > FreeBSD 6.x to track the 7.x stable ports branch if they want. Or not, > depending on ports developers. > >> What if the supported lifetime of the port upstream is less than >> supported lifetime of FreeBSD branch? > > Only if an update is needed (e.g. for security purposes), either of these: > > 1) Some other OS, Linux distribution, etc. nags the developers to fix it > upstream or do the patch themselves, which we can pick up > 2) The port maintainer(s) do it themselves (discouraged, of course) > 3) The port is marked as insecure (possibly in vuxml) and the users are left > to nag the developers for #1 or #2 :) > > If there is no immediate pressing need to update such a port (e.g. > security), people can run arbitrarily old versions of applications forever. > Or track HEAD. > >> Who will backport at least >> security fixes to the port? > > I'd suggest that, previously to including the port in the "stable" branched > the maintainer(s) agree to do it if necessary. Of course, it would be > completely voluntarily - no maintainance, no stable port. It would defeat > the purpose. > >>> * 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 > > Outdated beasts tend not to change much. > >> to be updated? In other words what is the difference between proposed >> "stable" ports branch and a static snapshot? > > The static snapshot doesn't magically evolve Apache from 2.2.0 to 2.2.14+ > but deliberately stays away from 2.4.0 because it would break its ABI and > require recompilation of its modules :) > > As others noted, shared libraries are the issue - if a port, during its > update, bumps its shared library version (libsomething.so.1 -> > libsomething.so.2), it would *not* *ever* be upgraded in the stable branch. > >>> * 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? > > Yes it could. This is really tangential for the discussion, it concerns more > the "next step" - binary packages and updates. > >> 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... > > Yes, of course. Most of the problems here are not technical but > organizational. Creating a package manager is relatively easy compared to > the project infrastructure (peopleware) that need to support it. > >> Weighting these all, I would say no. There is already enough fun keeping >> ports working on CURRENT. And see below. > > Ok. > >> Back on topic, would not it be better to provide "official packages for >> upgrades" built from some chosen snapshots of the ports tree? > > No, since it doesn't solve the major problem of forced upgrades of entires > subtrees when an ancestor changes (e.g. libgtk, libpng, libjpeg, qt). > >> In some cases (when really needed?) there are already different variants >> of the same port (port / portXY / port-devel). > > This makes sense for a very small number of ports. E.g. having PHP 5.2 and > 5.3 at the same time in the same ports tree would probably add to the > confusion. > > But you *must* upgrade to latest php-5.x port because of security updates > and so you are forced to upgrade php to 5.3 (and everything that depends on > it) even when 5.2 is supported upstream. There is one important note to make: Many times you're forced to upgrade packages because of ABI breakages, etc. What would happen if there was a CVE assigned for PNG tomorrow (like there was for JPEG a year and change ago) where mass changes were required of 1k ports -- you could either have to bump the versions or patch _every_ single port like Dirk has been doing for the past week and a half (and is still doing... also with other folks' help thankfully -- poor guy). There are issues with underlying test tools that prevented the PNG upgrade from being a smoother one... Here's another potentially novel (or lame idea): has someone considered _labeling_ packages stable with branch tags instead of creating new branches? That way projects which are broken on certain OSes -- for a period of time, due to an underlying OS change like utmpx removal -- can be labeled STABLE (or equivalent) once the package has stabilized on branch / release X.Y.Z? Furthermore, people could check out packages with RELENG_* tags, and maintainers could use their best judgment to tag the files appropriate to the change being committed? Branch tags are used in the cvs side of the house at least for releases (src ala svn is a different matter entirely). I admit this is a horse of a different color, but it at least makes it [potentially] easier for committers to commit in segments instead of having to deal with the pain in the ass part of syncing changes between N release directories for branches if and when software breaks on different versions of FreeBSD -- just a thought. Also, another idea that was briefly underscored that I (and other folks more importantly) like is that release branches should only be updated for security releases. I admit, this is a pain in the rear with large / sweeping commits (JPEG/PNG anyone :/?), but at least it would ensure that stability is largely maintained. Thanks, -Garrett