yanefbsd at gmail.com
Tue Mar 30 07:26:41 UTC 2010
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.
>>> 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
>> 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:
(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.
More information about the freebsd-ports