"stable" ports?

[Alexey Shuvaev]

On Mon, Mar 29, 2010 at 05:57:04PM +0200, Ivan Voras wrote:
> Hi,
> 
> First of all, I'd like to have this particular discussion in the open
> with ports developers and maintainers. So please - if you are a "simple"
> user, without a port to maintain, you will be given another thread if
> anything comes out as a result from this discussion.
> 
To start with, the number of ports I maintain is not large at all,
and all of them are mostly "dark corners" never used.

> There is a discussion[*] currently in The Forbidden Palace about the
> possibility (it's just that - a discussion of viability) of having a
> "stable" ports branch which would in the future as a consequence enable
> building binary packages and deploying them in the way of Linux's "apt"
> and "yum" tools.
> 
> 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?

If this is the case, 6.x branch will have pretty outdated
"heavy infrastructure" ports (like gnome/kde libs, see below).
What if the supported lifetime of the port upstream is less than
supported lifetime of FreeBSD branch? Who will backport at least
security fixes to the port?

> Some more potential properties:
> 
> * Ports in the stable branch/overlay would be maintained with more
> rigorous checking.
>
Are the current ports not already rigorously tested? :)

> * 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
to be updated? In other words what is the difference between proposed
"stable" ports branch and a static snapshot?

> * 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?

> This is obviously pretty fuzzy - rules would need to be specifically
> made later.
> 
> The biggest problem would seem to be the burden this would have on ports
> developers vs the gains that could be gotten from this system.
> 
> In some cases the burdens are obvious - the maintainer(s) would need to
> e.g. maintain three versions of the ports - a random example would be
> e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be
> keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future
> (CURRENT/9.x) branch.
> 
> Some of the benefits are also obvious. The scheme would allow faster and
> more convenient updating of the system, without breakage of shlibs
> within a branch.
> 
> Within all this, I think one point is important: there should be no
> inventing of wheels or pioneering work on this. Much the same concepts
> are already proven to work with Linux systems (stable package branches,
> apt and yum), so this is not very much unknown territory. Here not be
> dragons :)
> 
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...

> I consider this just an opinion-collecting thread: Would you, as a
> maintainer / developer, be interested in something like this, and why?
> 
Weighting these all, I would say no. There is already enough fun keeping
ports working on CURRENT. And see below.

> [*] the discussion was started unexpectedly following my post bringing
> http://blog.hagander.net/archives/167-PostgreSQL-infrastructure-updates.html
> to attention.
> 
Quoting:
"... that will ensure that all our machines look the same way.
This also plugs into our monitoring systems very well,
making applying (security) updates across the many machines much easier. ..."

It's a pity that pgsql devs are not familiar with ports-mgmt/tinderbox...
Looks like it is exactly what they need. Maybe the README from tinderbox
deserves the place in the handbook
("Preparing packages in corporate environment" or something similar)?
Compiling the set of possibly customized (patched) packages for further
deployment on a large number of machines is an easy task when using
tinderbox.

Back on topic, would not it be better to provide "official packages for
upgrades" built from some chosen snapshots of the ports tree?
Then some community (portmgr?) would shape the flow of updates to the tree,
blocking the "sweeping changes" (and allowing all others?) during preparation
of the "snapshot points"? Something similar is already done during
releases. Updating one ports while holding the others sounds more like
repository manipulation rather than a real maintainance of different branches.
In some cases (when really needed?) there are already different variants
of the same port (port / portXY / port-devel).

Alexey.