On Fri, 2019-05-10 at 16:06 +0000, Miro Hron=C4=8Dok wrote:

Do we demand (by policy) that all shipped modules are built against a
supported release?

I think this is a good policy, and to your last point I would count
EPEL as "supported releases".

As discussed on the latest meeting:
Status quo: Currently, we can have modules built once (e.g. on Fedora 28), shipped everywhere (e.g. to Fedora 29, 30, 31...).
Question: What happens when Fedora 28 goes EOL? Do we demand (by policy) that all shipped modules are built against a supported release?
Notes:

We demand (by policy) rebuilds of regular Fedora packages. We do mass rebuilds. There is no such policy for modules.

Why does the policy not cover modular packages? What are the actual policies for modular packages? What other policies for ursine packages do not apply for modular packages?

It is surprising to me that they are not subject to mass rebuilds because there does not seem to be anything special about modules that implies that they should be of less quality than the ursine packages. And mass rebuilds are there to ensure that packages shipped for a newer release use the latest enhancements (hardening flags, GCC improvements, new scriptlets, ensure that they still build).

As discussed on the latest meeting:
Status quo: Currently, we can have modules built once (e.g. on Fedora 28), shipped everywhere (e.g. to Fedora 29, 30, 31...).
Question: What happens when Fedora 28 goes EOL? Do we demand (by policy) that all shipped modules are built against a supported release?
Notes:
We demand (by policy) rebuilds of regular Fedora packages. We do mass rebuilds. There is no such policy for modules.

Why does the policy not cover modular packages?

This is flat-out wrong. We do a mass-rebuild of all modules along with the regular packages. I'm not sure where @churchyard got that idea. However, we select the modules for the mass-rebuild process based on their buildrequires information (e.g. if they have buildrequires: [] or any other structure that would include the new release, it gets rebuilt).

So we wouldn't be mass-rebuilding the case described here, where it was only built on F28 but runs anywhere.

What are the actual policies for modular packages? What other policies for ursine packages do not apply for modular packages?

Ursine policies apply wherever they make sense. I think this "built once, runs anywhere" case is the first exception we've considered.

It is surprising to me that they are not subject to mass rebuilds because there does not seem to be anything special about modules that implies that they should be of less quality than the ursine packages. And mass rebuilds are there to ensure that packages shipped for a newer release use the latest enhancements (hardening flags, GCC improvements, new scriptlets, ensure that they still build).

As I said above, this is entirely false. They are part of the mass rebuild process. And, in fact, they actually end up mass-rebuilt twice because they have to be rebuilt both at mass rebuild if there is one and always at the Branch Point, or else Rawhide doesn't get them.

I'm not sure where @churchyard got that idea.

Sorry, the idea is that for modules that build on one platform and ship everywhere, there is no such policy. Edited.

I’ve been thinking about this today. I think we want the following policy:

“Any module that is capable of building against one platform but running against all of them must be always be built against Rawhide to ensure that it is always taking advantage of the latest features, optimizations and security enhancements. If it cannot be built against Rawhide, it will be treated according to the FTBFS policy. Exceptions may be granted at the sole discretion of FESCo but must be resolved properly before the Beta Freeze of the following release cycle.”

I'm afraid that from the backward-forward compatibility POV, this isn't good.

AFAIK Packages built against older glibc etc. will work with new glibc etc., but not the other way around.