"stable" ports?

[Garrett Cooper]

On Tue, Mar 30, 2010 at 12:26 AM, Garrett Cooper <yanefbsd at gmail.com> wrote:
> On Tue, Mar 30, 2010 at 12:18 AM, Garrett Cooper <yanefbsd at gmail.com> wrote:
>> 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.
>
> 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