From owner-freebsd-ports@FreeBSD.ORG Tue Mar 30 07:30:54 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 D7F78106566C; Tue, 30 Mar 2010 07:30:54 +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 72A068FC0C; Tue, 30 Mar 2010 07:30:54 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so652005qwe.7 for ; Tue, 30 Mar 2010 00:30:53 -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=eZZ19I9FuodQMuccFQ+jeHcJ44w5NkYDGyhrQ3m2kKs=; b=NmIuJX61cByaRHh765aoByxB5Tm63KNlkRU31lVqSXPjuQpiGjfGZXrizbacuvpnNL QCBgeCKZlqHoNhgPkwRltQ7pzEUp6ZH5Hh0Irgytjix1LX5tyYPvT0nuRYD69e/nq6AE 9rhjbWdEM1peh2idq1chUUOMgQc6ROJIOmvd4= 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=Lr/89gE7csp5jUz0TOw1X4p8LP5WoKxXRAF0580a3JxEvWetj+lmh0vx2vIa4n/a+3 Ds/dllijVd96KfDpFfdW74+8mWlVd++0Hv+3oUWD7yitqfmwZ72dS9PEGltTWPo0LZxl VRFl0V6CBi+6g8tCBXkimsOdPJSUxJ91tPUGQ= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Tue, 30 Mar 2010 00:30:53 -0700 (PDT) In-Reply-To: <7d6fde3d1003300026qa537f77j239931591b64e7e@mail.gmail.com> References: <20100329172753.GB39715@wep4035.physik.uni-wuerzburg.de> <7d6fde3d1003300018gf395446g703cd287c6265a76@mail.gmail.com> <7d6fde3d1003300026qa537f77j239931591b64e7e@mail.gmail.com> Date: Tue, 30 Mar 2010 00:30:53 -0700 Received: by 10.229.184.195 with SMTP id cl3mr883239qcb.106.1269934253624; Tue, 30 Mar 2010 00:30:53 -0700 (PDT) Message-ID: <7d6fde3d1003300030q34d9a839l9d3e44ce24405d@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:30:54 -0000 On Tue, Mar 30, 2010 at 12:26 AM, Garrett Cooper wrote: > On Tue, Mar 30, 2010 at 12:18 AM, Garrett Cooper wrote: >> 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. > > To answer my own question (shortly after I posed it), yes re@ is > tagging ports. Example: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/ports-mgmt/portmaster/Makefile > (look for RELENG_7_3_0 for example). > > Maybe this tagging should be extended quarterly to include updates > like tmlaugh@ was suggesting, as well as STABLE? Seems like a rather > trivial thing to do to solve this problem -- and literally nothing > needs to change as re@ is taking care of the major and minor release > tagging -- maybe portmgr@ should do the quarterly snapshots? Sorry -- one last thing to kick around before I get off this topic: If this is really slick and tinderbox / whatever tools is doing its job and no PRs have been reported for X number of days on a given port (would require tie-ins to GNATS, or whatever), perhaps it would be nice if ports were automatically `promoted' from HEAD to STABLE? I mean, why do something if a computer can do it for you, right :)? >> 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