IPD 59 Sysroots

[pfmooney]

No description provided.

[Toasterson]

Do we want to include notes about ARM and SPARC sysroots in this IPD? Klaus created one yesterday and since SPARC has not so many LTS versions, those sysroots will probably be built on a different basis. https://dlc.openindiana.aurora-opencloud.org/SPARC/illumos-sysroot-sparc-custom-v20260107-145026.tar.gz

We could specify that this sysroot document is x86 only. Other Architectures can use a different base as sysroot without a conflict as far as I can tell.

I love it for x86.

[pfmooney]

Do we want to include notes about ARM and SPARC sysroots in this IPD?

Only x86_64 is in scope for now. I've added language clarifying that position.

I imagine we'll revisit the arm64 situation when that port is lining up to land in illumos-gate. As for SPARC, I think it would be left up to the folks who are maintaining that platform outside of upstream illumos-gate to coordinate on what/how they wish to do?

[ptribble]

Having this all set up formally is an excellent inititiative. Thanks!

OK, some comments/questions:

One is the issue of support timelines. The situation is practice today is that any individual release is only officially (if at all) supported for less than 3 years. However, that seems really quite short, and I suspect that there are plenty of people out there running releases much older, and it may be that someone may wish for a longer support timeframe. What I don't want is for the fact that we're publishing a 3-year old sysroot to be interpreted as an official position on support timelines - perhaps we just need to be absolutely clear that the age of a sysroot is arbitrary.

It goes the other way, too. Is there any reason not to have newer sysroots available? After all, that's the way for projects to gain access to newer features, and to test against current releases - if there's a problem, we don't want to have to wait 3 years to find out. It may also be easier to create a current sysroot now, rather that having to specifically install a downrev build system.

The second thing is about the choice of commit. In terms of new features, what really matters is what's present in libc, which is described by the versions listed in usr/src/lib/libc/port/mapfile-vers. (I know we may fix bugs in eg, headers, that won't get captured here, but by and large it's changes to the mapfile that correspond to the evolution of the system's interfaces.) In other words, we should create a sysroot and tie it to the symbol versioning there, rather than an arbitrary date or commit. In other words, something like ILLUMOS_0.57 is far more useful in some ways as a description as it attaches semantic meaning to the sysroot.

(Which makes me think that we as distributors need to do a better job of tracking the symbol version of libc and its relationship to releases., as that is a key description of compatibility.)

With the above in mind, if we're mapping a sysroot to an OmniOS LTS release, then what we need is the commit that introduces the libc version appropriate to that OmniOS LTS release. I don't think we can assume anything that involves dates; I've certainly been burnt in the past when OmniOS took longer than expected to catch up, and ended up shipping software that required a later libc than OmniOS had.

[pfmooney]

Having this all set up formally is an excellent inititiative. Thanks!

Thanks for spending the time to review and give feedback!

What I don't want is for the fact that we're publishing a 3-year old sysroot to be interpreted as an official position on support timelines - perhaps we just need to be absolutely clear that the age of a sysroot is arbitrary.

Yes, that's a good point, and I'll clarify it in the document.

It goes the other way, too. Is there any reason not to have newer sysroots available?

That's a good question. One could imagine that if newer sysroots were published, that it may be tempting for external projects to use the latest one, inadvertently breaking that 3-year compatibility window that we strove to create.

After all, that's the way for projects to gain access to newer features, and to test against current releases - if there's a problem, we don't want to have to wait 3 years to find out. It may also be easier to create a current sysroot now, rather that having to specifically install a downrev build system.

Regardless of where we land on making newer sysroots officially available, I hope that through this IPD (and subsequent efforts), that it will be relatively straightforward for anyone to generate sysroots on their own for testing and the like.

The second thing is about the choice of commit. In terms of new features, what really matters is what's present in libc, which is described by the versions listed in usr/src/lib/libc/port/mapfile-vers. (I know we may fix bugs in eg, headers, that won't get captured here, but by and large it's changes to the mapfile that correspond to the evolution of the system's interfaces.) In other words, we should create a sysroot and tie it to the symbol versioning there, rather than an arbitrary date or commit. In other words, something like ILLUMOS_0.57 is far more useful in some ways as a description as it attaches semantic meaning to the sysroot.

I would argue that the collection of things outside and independent of libc (and its declared symbol versions) make it somewhat risky to use that as the authoritative version declaration, rather than the date (and commit ID). Changes to headers (like #16200), or the inclusion of new Committed libraries could certainly fall out of step with libc itself.

With the above in mind, if we're mapping a sysroot to an OmniOS LTS release, then what we need is the commit that introduces the libc version appropriate to that OmniOS LTS release. I don't think we can assume anything that involves dates; I've certainly been burnt in the past when OmniOS took longer than expected to catch up, and ended up shipping software that required a later libc than OmniOS had.

To be clear (and perhaps the IPD should do more to state this?), while this proposal intends to use the OmniOSCE release schedule as a guide for when we choose the sysroot snapshot timing, the contents themselves come from illumos-gate, not illumos-omnios.

[jclulow]

Thanks for doing this, Patrick! It looks good to me.

[jclulow]

I think for all of these it's good to not be overly prescriptive. I think "in May", and "we can consider specific backports or other things as they arise" is all very reasonable for now. We're moving from what has essentially been a one-off in 2020, to an annual thing, which feels like a good enough first change!

[nshalman]

Yes, as someone who had this concern after being bitten by the header bug I want to make clear that solving this should not be a blocker for making progress. I'm just happy to have it noted here as a thing we might have to worry about some day.

[jclulow]

Do we want to include notes about ARM and SPARC sysroots in this IPD?

I agree that we definitely don't want to do this. I'm excited for ARM to arrive as well, but until it does we don't want to send out confusing signals!

---

With respect to headers and libc versions, I agree that we don't want to do that: for one thing, libc is not the only public versioned library, so it seems wrong to frame the version that way. I think there are also cases where we have adjusted the headers, as Patrick notes, in ways that are not visible through library versioning.

[pfmooney]

Given that there's been no other discussion, and @gwr has stepped up as an IPD sponsor, I'm going to move this into the published state. Thanks for your review and consideration.

[nshalman]

Thank you!

[pfmooney]

Merged as 2272710