"stable" ports?

[Garrett Cooper]

On Mon, Mar 29, 2010 at 11:35 AM, Ivan Voras <ivoras at 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.

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