svn commit: r312910 - in head: . etc/etc.pc98 etc/rc.d lib/libsysdecode libexec release release/doc release/doc/en_US.ISO8859-1/hardware release/doc/en_US.ISO8859-1/readme release/doc/share/example...

[Alexey Dokuchaev]

On Wed, Feb 01, 2017 at 03:39:57PM -0600, Mark Linimon wrote:
> On Wed, Feb 01, 2017 at 08:09:50PM +0300, Slawa Olhovchenkov wrote:
> > Also, I am think current ports don't build on 4.x.
> 
> I will personally guarantee, in writing, that current ports do not build
> on 4.x, nor have they done so for years.  I personally removed the legacy
> cruft when 4.11 finally went EOL.

They don't build as is, but they still can be tamed (patched) to build and
install nicely on 4.x with some effort.  Most remaining 4.x installations
are server ones which typically carry a well known selection of ports that
are not hard to maintain locally for 4.x compatibility.  One does not have
to have *entire* tree to build flawlessly on 4.x.

> > I am got complains about using ports on 8.x.
> 
> I am 99% certain that ports will not work on either 8.x or 9.x.  Legacy
> cruft was removed at the EOL in each of those cases.

That's quite wrong actually: most ports build and run just fine on 8.x
(X.org stack is one major exception), with some fairly trivial changes.

> Anyone who think that we can support ports on 4.x, 5.x, 6.x, 7.x, 8.x,
> 9.x, 10.x, 11.x, and -current, all at the same time, needs to seek medical
> attention at once.

Well, we're doing something more than devoid any support claims: we're
deliberately breaking it, often for little to no reason.  Things like
r431746 are disgrace to FreeBSD and utter disrespect to our users. :-(

> At the absolute least, that era spans 3 major versions of make(1) and
> two completely different package implementations.

That's largely irrelevant and hardly ever causing problems.  All needed
make(1) implementations are available in ports; I can still build modern
ports in 8.x tinderbox with WITH_PKGNG=yes/PKGSUFFIX=.txz.

./danfe