On 23/6/17 4:38 pm, Vlad K. wrote:
On 2017-06-23 10:26, [email protected] wrote:
Release branches won't have many maintenance except individual bug
fixes when security advisories are found. No backport, no updates.
Nothing prevents the maintainers from doing exactly that right now.
But you see, there are two kinds of ports in the tree:
1) ports where upstream maintains a concept of LTS
2) ports that mix bug, security fixes and new features in even
point.point releases
For some (all?) major production software like Apache, nginx, PHP,
PostgreSQL, MySQL (I think?), Postfix, Dovecot2, etc... #1 applies.
So for serious production servers this should be easy to maintain as
the upstream is doing that in the first place.
The problem is then with ports of type #2. And there's lots of them.
Gentoo portage can easily maintain "stable" ports because portage
doesn't have a single Makefile, it has multiple .ebuild files so
multiple versions are available under ONE port name, and bumping the
version while keeping previous ones available is literally just a
matter of making a copy of the latest .ebuild and fixing the version
in it like we do with PORTVERSION.
This is why I think our Makefile should be split up into two parts.
One of which has the interface to the rest of the ports and one of
which specifies what to download and things that are specific to a
given version.
then hopefully you could update the second without changing the first.
Harder to do than say, I know, but I have faced htat challenge soo
often, in fact i have it right now.
I need a new azure-agent, in a 10.3 world, where I can not update any
other packages/ports.
On FreeBSD that's impossible and often ports are separated and
version baked into the port name. Like www/node from the original
post of this thread.
But again, that's all doable without having to introduce new
infrastructure. The ports tree as is can be maintained like this and
quarterly repos would NOT be required. All it's needed is for
maintainers to keep a stable version and a latest version. There's
already plenty of ports done like that, otoh postfix and
postfix-current, nginx and nginx-devel, etc...
Because the BIGGEST problem in maintaining separate "stable" or LTS
branches is BACKPORTING fixes for ports in the #2 category, ie.
those that mix new features with fixes, so you have to CHERRY PICK
only the fix and BACKPORT it to your "stable" branch. And that's
even more work often introducing NEW bugs.
BTW, the problem of the original post could've been avoided if the
user only read UPDATING which clearly stated that www/node becomes 7
and previous node (6) becomes www/node6. (20161207) entry.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
