Date: Tue, 30 Mar 2010 00:26:39 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-ports@freebsd.org Subject: Re: "stable" ports? Message-ID: <7d6fde3d1003300026qa537f77j239931591b64e7e@mail.gmail.com> In-Reply-To: <7d6fde3d1003300018gf395446g703cd287c6265a76@mail.gmail.com> References: <hoqikd$o2h$1@dough.gmane.org> <20100329172753.GB39715@wep4035.physik.uni-wuerzburg.de> <hoqrtp$u16$1@dough.gmane.org> <7d6fde3d1003300018gf395446g703cd287c6265a76@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 30, 2010 at 12:18 AM, Garrett Cooper <yanefbsd@gmail.com> wrote: > On Mon, Mar 29, 2010 at 11:35 AM, Ivan Voras <ivoras@freebsd.org> 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? > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d1003300026qa537f77j239931591b64e7e>