Date: Mon, 23 Jun 2014 22:24:10 -0400 From: Glen Barber <gjb@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Craig Rodrigues <rodrigc@FreeBSD.org>, Brooks Davis <brooks@freebsd.org>, Dimitry Andric <dim@freebsd.org>, "Simon J. Gerraty" <sjg@juniper.net>, freebsd-current Current <freebsd-current@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org> Subject: Re: Problems building FreeBSD 9.2 on FreeBSD 10 Message-ID: <20140624022410.GP1218@hub.FreeBSD.org> In-Reply-To: <60320DD3-56C4-4922-A537-FF94C392A45A@bsdimp.com> References: <CAG=rPVfanU=FVWPd768_G5NjXRHnUH5o05%2BKwFeLaTQqU3Ux8w@mail.gmail.com> <FC1B2983-4B49-4480-855E-6BD09B148F31@bsdimp.com> <CAG=rPVd5XGz8hfuBtcOuuZp8ND1ssWoTkVNn0Hg6Li_2-NrgcA@mail.gmail.com> <1ED3AC7E-0F74-46A7-BAAA-E30600DC23BB@bsdimp.com> <CAG=rPVeP32=y3VZgn0MXFPrr8tevL=jOsCow=rvpxRevmvoLqA@mail.gmail.com> <8CD24B0A-DF45-4437-BEBE-8C67B241DE93@bsdimp.com> <CAG=rPVcrJpP_1VcKZnsxAugBywJBXg63p2piX7nPndTunPEWDQ@mail.gmail.com> <2063888D-CCAE-431B-A409-F17AA4422006@bsdimp.com> <20140624011251.GN1218@hub.FreeBSD.org> <60320DD3-56C4-4922-A537-FF94C392A45A@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--uQTKok2xqDOM7hgb
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 23, 2014 at 07:42:27PM -0600, Warner Losh wrote:
>=20
> On Jun 23, 2014, at 7:12 PM, Glen Barber <gjb@FreeBSD.org> wrote:
>=20
> > On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote:
> >> On Jun 23, 2014, at 6:15 PM, Craig Rodrigues <rodrigc@FreeBSD.org> wro=
te:
> >>> So, I guess that stable/9 can build properly on a stable/10 box.
> >>> For FreeBSD 9.2, there is no easy way out.
> >>=20
> >> You=E2=80=99ll have to back port the patch then. We don=E2=80=99t guar=
antee forward
> >> compatibility like this since 9.2 is frozen in time now.
> >>=20
> >=20
> > I'd really like to discuss rethinking our forward-compatibility
> > policies, since we have (now) 3 active stable/ branches, plus head/.=20
>=20
> Generally, in the past, the rule has been =E2=80=9Chead will build from t=
he last stable branch tip.=E2=80=9D This was extended, for a while, to =E2=
=80=9Clast stable branch point=E2=80=9D when Ruslan made sure that worked. =
While -stable has generally built on -head, this was never part of the cont=
ract. It usually did, but is very very hard to guarantee given the nature o=
f head=E2=80=99s tools changing in ways that are allowed for head, but that=
break prior branches.
>=20
I sort of typed what I meant a bit backwards from what I intended to
write. What I meant (sort of) is, "I would like to discuss our forward
thinking on backward-compatibility."
I fully understand forward-compatibility is not feasible.
> > What I would like to see, with my RE hat on, is a "best effort"
> > backwards compatibility to being able to build the lowest-numbered
> > supported stable/ branch on head/.
>=20
> I think, that as in the past, this will generally work. However, it won=
=E2=80=99t always work. Things break in this area a lot. More than you migh=
t think, especially with the huge amount of churn we=E2=80=99ve had wrt com=
pilers, make, etc. I suspect that new imports of clang will break this ever=
y time, since every import of clang has required changes to the tree to eit=
her disable warnings, or to fix newly flagged things. I suspect there will =
be a lot of churn here, and releases will go stale the fastest=E2=80=A6 Wit=
h -current starting to support building multiple versions of clang (and gcc=
), there=E2=80=99s hope for the future, but back-porting this code is beyon=
d what I have the time to do. That=E2=80=99s going to make things increasin=
gly difficult as we march forward.
>=20
I hate to even suggest this, but the ports tree (ab)uses the notion of
using the kern.osreldate for certain things. This, however, requires
proper bumping of __FreeBSD_version when needed, and maintenance of the
Makefiles for the kern.osreldate-specific things.
The benefit to this is that it would help prevent pissing off ports
developers and make their lives a bit easier when userland / kernel
things change. It would, however, (expectedly) is that it would force
src committers to do the right thing. Win-win, IMHO.
> This isn=E2=80=99t even getting into cross build scenarios=E2=80=A6.
>=20
> Or building releases, which is a whole different set of lightly tested co=
de that is mostly host independent, but sometimes isn=E2=80=99t as much as =
you=E2=80=99d had hoped...
>=20
> > Sure, this won't always work, but "best effort" is better than "no
> > effort", which the latter is why we do not have stable/8 snapshot
> > builds, to be honest. I won't spend the time on the stable/8/release/
> > code nor the snapshot build scripts to waste the time. Building
> > stable/9 on head/ is annoying alone.
>=20
> stable/9 builds on head. If there=E2=80=99s a race, that needs to be fixe=
d in stable/9. That=E2=80=99s quasi supported because people do it. The =E2=
=80=9Cbest effort=E2=80=9D involves people that are interested in the bugs =
being fixed fixing them, or convincing others to fix them. For me, this sce=
nario is outside the area I care about, have the ability to test, or have t=
ime for.
>=20
> So =E2=80=9Cbest effort=E2=80=9D involves more than me making an effort. =
I may or I may not. It all depends on my time and inclination. If it is goi=
ng to work, bugs need to be fixed in stable/9 that prevents it from buildin=
g on head, while not breaking the ability to build on 9. So there=E2=80=99s=
a lot of heavy lifting that will be needed in short order to keep this wor=
king once the clang folks can figure out how to get past the angst of the u=
pgrade path and push forward to 3.5. Some architectures will break when tha=
t happens, no doubt.
>=20
Personally, and no I won't discuss more on this, I'm in the camp of "I
don't really see clang as a feature." It caused our ports developers
and maintainers a mountain of headache to convert to the "invisibly new
great thing", it increases our overall buildworld by a non-insignificant
amount of time, and it has personally caused me headaches (still
ongoing) trying to figure out what the correct incantation of evil to
wish over the cauldron to get BeagleBone images to build. (They're
failing because gcc is not being installed on both head/ and stable/10/,
and despite the game of "musical KNOBS" I've been playing over the past
few days, I'm running out of hair to pull out of my head.)
> But 9.2 will never build on head because it is broken with bmake, which i=
s now standard for head. Since 9.2 cannot be changed, and since we=E2=80=99=
ve removed (or nearly) fmake in current, chances are quite good it will nev=
er build on head again without some special handling.
>=20
> In summary, good luck! there=E2=80=99s a lot of use cases here, and it wi=
ll take time and effort of multiple people over the long haul to keep it wo=
rking. Best effort may be larger than you estimate=E2=80=A6 I won=E2=80=99t=
stand in your way, but I=E2=80=99m afraid my time available to help is lim=
ited.
>=20
As Ozzy once sang:
"I'm just a dreamer
I dream my life away
I'm just a dreamer
Who dreams of better days"
Glen
--uQTKok2xqDOM7hgb
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJTqOFKAAoJELls3eqvi17QclwP/igEY3Xr3gw7TxNqV/fvnajx
DU/qot6vEjte/HP2bjXvBMpwjZmM3PHPBF5ioQKZAmYBgDIMMzk28qjpnxCVws0f
fPonBONxRO/X+AYn7EkRsuVftEgbE0/0E5XkGxFHX+NqpJWRieoJeu9ptRCi1TtS
eG+oUKblpmaC/mntOTP40XlvXi3DxWKemH/eNMVP0TSEImZYwT4C9ROPLICPrutz
hldN6+whhCoSc6538Nv8+AEZrBKmw7LusPet88a7Pyt3+c7+xfWI3ytHoIHhVaR3
w7WB/G+v7kGPtTdKlKSkTEXAi2NzRwOxIscBpd0KRJWXJgBxoEqhvd65x6fVlxgB
mu0Xg7Hw0r/v8gVxcTOAdVm4w/DTwOtarbaQ8dduPhwMPFY6aWLY6VEeg2iABm3o
ajJiSfeVSzRjumjHH82MOQT2HsTT0AXoQwg1uaJLLhHNevSgtdGFN1SfsA6cf/7W
1SGVHqrqnqgE1TU2V18IWMTS8X7RjZXqPCafknJ86tT0fs7RbDm7Kzm/VqcBx3WM
tWO8y0nAIvKcNgIEknaM1mwquDPAh3bO+AkhjBw9OFfGBDFCPWqHE9RaBT8zh3Ux
GFzphcVPPx8qbw/Cz2t8raWMjVzTt5ga4X5/2wQSmS8VlCup4L9uZTouCnkaa2U6
VrBwxXOS8TRXTRk3UfSI
=J8Vd
-----END PGP SIGNATURE-----
--uQTKok2xqDOM7hgb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140624022410.GP1218>