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.
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
