Date: Mon, 29 Mar 2010 20:35:24 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-ports@freebsd.org Subject: Re: "stable" ports? Message-ID: <hoqrtp$u16$1@dough.gmane.org> In-Reply-To: <20100329172753.GB39715@wep4035.physik.uni-wuerzburg.de> References: <hoqikd$o2h$1@dough.gmane.org> <20100329172753.GB39715@wep4035.physik.uni-wuerzburg.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hoqrtp$u16$1>