The best (least disruptive) policy, in my opinion, would be:

No default streams.
// Switching from a default stream to another breaks other packages
// depending on the default stream.

Packages MUST NOT be moved from the distro to a module if any other package depends on them.
// Look up for "viral" in ticket https://pagure.io/fesco/issue/2114#comment-655663
// Having a package that other non-modular packages need
// available only in a module breaks the distro.

Modules MAY be used to package alternative versions/builds of software

• a new stable version of a software stack that cannot be included in the current Fedora due to incompatible changes
• an unstable version of a software stack (rawhide builds backported to stable Fedora)
• builds with different compilation options (debug builds, minimalistic builds, builds with extra features, ...)
• non-debug builds (e.g. an alternative to rawhide's debug kernel)

Modules MAY be used to package software that is not in the distribution

• software that usually ends up in COPR, but should be brought closer to Fedora users
• backports from Fedora to EPEL

Why compact packages and parallel installable packages are not suitable for modularity? I think that compact packages is an approach how to remove some strong rules from modularity like:
1. Packages override -> modular filtering by name and provide
2. Fail-safe - the upgrade path for modules and non-modular packages will be preserved without modular metadata
3. Hotfix repositories will be not needed.

@dmach Why do you want to ban default streams if you're also banning modularizing packages with reverse dependencies? If there's nothing that depends on you, you can't break anything by switching.

The proposal mandates the use of filter for build-only components but I believe there is another option to do that, buildonly. Even though MBS translates this into filter in practice, the proposal implies people have to define the filter manually.

First, I forgot to mention that there's a preview that's easier to read at https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/

The best (least disruptive) policy, in my opinion, would be:
No default streams.

It's a balancing act; if we allow default streams, it becomes possible for people to maintain packages in modules only. To give a practical example of this, right now I have to maintain Node.js 10.x, 12.x and 14.x as modules, then I need to build 12.x as non-modular for F31 and F32 and 14.x as non-modular for F33. With default streams, I can just build all three Node.js versions for all the releases and then set which one is the default for each.

// Switching from a default stream to another breaks other packages
// depending on the default stream.
Packages MUST NOT be moved from the distro to a module if any other package depends on them.

This is exactly no different from non-modular behavior though. Updating a major component like Django in the non-modular repository breaks other packages too. I forgot to include it in the first draft of the release, but I intended to say also that default streams may only be changed between releases IFF FESCo approves a submitted Change.

// Look up for "viral" in ticket https://pagure.io/fesco/issue/2114#comment-655663
// Having a package that other non-modular packages need
// available only in a module breaks the distro.

Uh... that is addressed by default streams. Do you see some specific case I'm missing?

Modules MAY be used to package alternative versions/builds of software

a new stable version of a software stack that cannot be included in the current Fedora due to incompatible changes
an unstable version of a software stack (rawhide builds backported to stable Fedora)
builds with different compilation options (debug builds, minimalistic builds, builds with extra features, ...)
non-debug builds (e.g. an alternative to rawhide's debug kernel)

Modules MAY be used to package software that is not in the distribution

I'm not sure what you mean here... Modules cannot carry any package that does not exist in dist-git...

software that usually ends up in COPR, but should be brought closer to Fedora users
backports from Fedora to EPEL

Why compact packages and parallel installable packages are not suitable for modularity? I think that compact packages is an approach how to remove some strong rules from modularity like:

OK, apparently that distinction isn't clear to non-native speakers. "Not well suited" is not the same thing as "not suitable". Think of it more like "recommended against" rather than "can't be used". I'll try to rephrase it.

1. Packages override -> modular filtering by name and provide
2. Fail-safe - the upgrade path for modules and non-modular packages will be preserved without modular metadata
3. Hotfix repositories will be not needed.

I think this is another language-barrier thing in the other direction. I don't know what you're trying to say here. It looks like you're drawing conclusions without providing the context. Could you elaborate please?

The proposal mandates the use of filter for build-only components but I believe there is another option to do that, buildonly. Even though MBS translates this into filter in practice, the proposal implies people have to define the filter manually.

I'll try to make that more general. I forgot that the buildonly feature landed in production MBS.

I rephrased the sub-headers for the "To Modularize or Not" section and replaced data.rpms.filters with a requirement to use buildonly, since that makes more sense going forward (and is more maintainable).

https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ has been updated with the current edits.

Could you please provide rationale for the cases where modules should be strongly considered? What are the benefits for the users and for the dependent package maintainers over non-modular packages?

(I realize that for the module maintainer, the benefit has been already mentioned, but in my point of view, this does not outweigh the impact on the users and dependent package maintainers.)

I fully support the modularity team tech lead opinion here described in https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310

I don't really understand why would Fedora encourage default streams if the technology maintainers don't agree. It is very confusing.

I fully support the modularity team tech lead opinion here described in https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310
I don't really understand why would Fedora encourage default streams if the technology maintainers don't agree. It is very confusing.

To clarify my opinion:
I'm not saying Fedora must not use the default streams, but I strongly discourage it because I believe it's going to cause problems and confusion.
If Fedora decides to use default streams, they MUST enforce a policy that non-modular packages MUST NOT depend on any stream content. Otherwise switching the stream from default to another would simply break these non-modular packages. And this also comes with explaining the packagers that some packages are treated differently than others. I personally consider this a bigger problem than explicitly enabling a stream if I want to consume it.

That is pretty much what I think as well.

I suggest that the policy must mentioned that modular content must not break the rest of distribution and that responsibility for distribution stability is also in hands of maintainers of modules..
The requirement must be valid for all of streams and not only to default one. Why I propose it? I have a feeling that there is misunderstanding between
packagers and users. Packages could think that modules are like containers, isolated systems, with only one purpose. But end users expects that alternative content will work like
a default deployment. Before anyone starts to argue, please check Bugzilla to see what users reports as problems. What we know for 100% that there is no problem with leave packages in modules that do not overlap something else.

I agree with @dmach and @jmracek on the default streams

TL;DR: Default streams with the currents status quo can work on one-purpose machines, but they are not suitable for multi-purpose machines (like desktops and workstations).

Reasoning:

Yesterday, during the modularity discussion, Terry pronounced two important problems that we need to solve:

1. Fedora is too fast for some users to build their courses, lectures, and examples on, i.e. we should provide a similar approach as an LTS would.
2. We would like to attract users from the Ubuntu world into Fedora.

I have spent the last twenty years evangelizing Linux among the Windows users and their objections to switch have been always the same: too different from what they already know, too difficult to administer, lack of applications with "professional" quality, "weird" desktops. If I remember well, anyone from those people who tried Linux decided to go with Ubuntu, because it is closer to their Windows way of doing things. Ergo, if we want to attract Ubuntu users, we definitely must make sure we serve these desktop users well, too.

If I understood correctly what @psabata said about the modules yesterday that it is not modules' requirement to be mutually compatible, because this is not what they are meant to be. Then, I read this as you can switch to a a slow modular stream for one thing, but you might not be able to choose a faster modular stream of another thing, because they might not be compatible. If I understand this correctly, then I believe we have a serious problem for a typical desktop user.

From what I have observed among young people at schools and about professionals at work, we believe that a typical desktop user might be one of the following:

• they want to have the newest applications to keep pace with their Windows friends (fast)
• they want to experiment with different applications and typically install and remove them often (many applications in repos)
• they want to, if they are professionals in some field, use a stable and tested applications for their tasks (DTP, video and audio production, etc.). (slow and stable)
• they want an eye candy desktop environment (like MacOS possibly) (well tested and curated DE)
• they need to switch between different versions of applications (parallel instalability)

The problem is that a real user belongs to all of these groups. In some use cases, they need to be slow, in others they need to go fast, which I believe brings the following expectations for modulartity:

• I want to install an application that moves faster (or slower) than normally, however
• I want to install another application that moves the opposite way.
• I want to install many applications for whatever reason I have.
• I want my system stable.
• I want to upgrade my system flawlessly without any issues.
• I want all my applications present and working after an upgrade.

If modularity with default streams should cover these use cases on a Fedora-wide level then I believe it must meet the following criteria, otherwise I cannot imagine how we could provide the above functionality:

• The default streams must be compatible across all modules.
• All modular streams must be compatible, too, because you never can predict who wants to consume which stream.
• It must be possible to switch streams without breaking other applications.
• All modular streams should have an upgrade path and if one stream gets obsoleted their must be a clear and user friendly way to handle the problem (switch to default, switch to another one, do not switch and keep this stream [but do update the rest of the system])

For me, default streams (that are not mutually compatible) can work well on a one-purpose machine (server, VM, container) but they cannot work on a multi-purpose desktop system unless the above requirements are solved.

If we keep default streams out of Fedora, then we make sure only those users who really find it useful and needed will switch to it, while the rest of the users will still have their stable non-modular system. And they will only switch it on, when they need.

I believe that if the requirement of having default streams was dropped, we'd need a couple fixes here and there, and modularity could be ready to use. Of course, that would not solve the situation for the packagers. However, even the packagers are Fedora users and they might want their system stable and solid to work and play with.

Some initial feedback from me. I will provide more later.

Packages with a stable and an experimental release.

This essentially means whole GNOME. I think only experimental version could go into the module, the stable one should stay non-modular and be upgraded to new stable when that comes out.

Packages with a build-time-only dependency that would otherwise conflict with the Fedora buildroot.[2]

Unfortunately this is too vague for me. Let's say you need older sphinx, that needs older python3 (let's say because it is not compatible with python 3.99). Which packages do need to be in the module and who is supposed in this case maintain them? In which cases is it allowed to have such conflicting packages?

I think instead we should tell people to adopt newer tooling and send patches to upstream. This is one of the things Fedora is cool that we push world forward.

Tightly-coupled packages that need to be rebuilt together.

Just a small nitpick, probably build together would be more appropriate.

Packages whose language ecosystem supports parallel-installation.[3] Where possible, parallel-installable methods are preferred in Fedora.
3. Examples: python packages, "compat-" libraries with different shared object versions.

This is not fully accurate, python packages are not parallel installable, in the way of multiple versions. It is, however, possible to do so but is complicated and requires patching of other software that wants to use them. Also "compat" libraries are not always parallel-installable (the -devel package I mean).

Agree that those are in the right section, but probably wording should be improved.

Packages provided at runtime by the default stream of a module MUST depend only on packages provided by packages from default module streams or the non-modular package set. By extension, default streams of a module MUST NOT have a dependency on any non-default stream.[4]

Since the tooling is nowhere ready to handle all workflows for modular packages, we need to figure out who is going to take care of FTI/FTBFS tracking for those components, who is responsible for doing mass rebuilds of those modules and how provenpackagers interact with these. More specifically, if I make a bump of SONAME of some library, who is responsible for rebuilding affected modules?

Also who is going to be responsible for the last sentence? Is there automated tooling for this?

If a default stream of a module has build-time-only components, all binary RPMs produced by those components MUST be marked as buildonly: True in the module metadata to avoid shipping them in the default stream.

Who is responsible for maintaining those buildonly components? Let's say libxml2-static exists in Fedora and module maintainer decided to build it as build-time-only component as part of their module. Then libxml2-static got some fix in Fedora that fixes a CVE. Who is responsible for rebuilding module with a proper fix, who is responsible for making sure that security bugs are properly handled in those components?

The default stream MUST NOT change within a released Fedora version. The default stream MAY change during Fedora upgrades.

The wording is a bit confusing, it can be interpreted as "once you build it, it will be shipped as-is until the next Fedora release".

Packages MAY convert from a non-modular package to a modular default stream (or the reverse) within a Fedora release, provided that the modular default and non-modular versions are version, API and ABI identical.[6]

Who is responsible for deciding whether some package can become modular-only? That's exactly what happened to libgit2. It was API/ABI compatible with non-modular and then the whole thing broke.

Since the tooling is nowhere ready to handle all workflows for modular packages, we need to figure out who is going to take care of FTI/FTBFS tracking for those components, who is responsible for doing mass rebuilds of those modules and how provenpackagers interact with these. More specifically, if I make a bump of SONAME of some library, who is responsible for rebuilding affected modules?

As the Python maintainer, this bugs me for a long time. I've opened a ticket for the Python case 7 months ago: https://pagure.io/modularity/issue/160

Unfortunately, there was no response what so ever. Such problems existed for a long time.

This conversation has gotten long and I think I need to clarify a few things:

1) FESCo (mostly @churchyard) asserted that ELN may not play with default streams until and unless "Fedora" has a policy. So I started crafting this. I intend this only to apply to ELN for right now, but I was crafting it to theoretically apply to the basic Fedora as well. If FESCo is willing to allow ELN to have its own separate policy, I can easily modify this to read "Fedora ELN" where it currently says "Fedora".

2)

Since the tooling is nowhere ready to handle all workflows for modular packages, we need to figure out who is going to take care of FTI/FTBFS tracking for those components, who is responsible for doing mass rebuilds of those modules and how provenpackagers interact with these. More specifically, if I make a bump of SONAME of some library, who is responsible for rebuilding affected modules?

Okay, that's a fair question. I think until the tooling is improved to better discover which modules depend on which RPM Provides, the best we can do is require that each module's maintainer is responsible for keeping track of this for that module. That said, I just had some thoughts on how we could make that more trackable/searchable and I'll see what I can do.

3)

Who is responsible for deciding whether some package can become modular-only? That's exactly what happened to libgit2. It was API/ABI compatible with non-modular and then the whole thing broke.

I think that's entirely up to the module maintainer. If the maintainer determines that making it module-only is the (subjectively) better approach for their project, they should be able to do that. This does not change the requirement (which is not in this document but is present in https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defaults/ already) that all default stream changes (adding, changing or removing) must be approved by FESCo through a Change Proposal. Put another way, I don't see any harm in a maintainer providing only non-default streams at their discretion if it makes sense.

4) @lruzicka You have defined a set of requirements that non-modular Fedora cannot possibly meet. Why do you think that modules should be held to that standard?

Non-modular RPMs still have Conflicts: that can result in preventing a subset of the OS to be uninstallable if you choose to pull them in. In designing Modularity, we had to weigh the relative merits of the cases you just described and decide which tradeoffs to make. That said, Modules should not introduce conflicts when it can be avoided. I can put that in the policy if you like.

As far as desktop applications, we strongly recommend the use of Flatpaks for this case, rather than using Modularity directly (Flatpak uses modules behind the scenes to create their containers). Flatpaks are the solution to address the cases you listed for the desktop user.

For server users, the reality is that the overwhelming majority of users use a separate VM or container for every application (for resource management and isolation), so the Module approach is a perfect one for those cases.

4) @lruzicka You have defined a set of requirements that non-modular Fedora cannot possibly meet. Why do you think that modules should be held to that standard?
Non-modular RPMs still have Conflicts: that can result in preventing a subset of the OS to be uninstallable if you choose to pull them in.

Hello @sgallagh , you have made a fair point here, however, so far I have only experienced conflicts between packages that provide similar content, such as a library for instance. Usually, choosing one of the providing packages does not exclude other applications from being installed and if something like that happened, I would consider it "a bug."

In designing Modularity, we had to weigh the relative merits of the cases you just described and decide which tradeoffs to make. That said, Modules should not introduce conflicts when it can be avoided. I can put that in the policy if you like.

Yes, if you could do add it, we would have a clear policy on how to treat it in QE.

As far as desktop applications, we strongly recommend the use of Flatpaks for this case, rather than using Modularity directly (Flatpak uses modules behind the scenes to create their containers). Flatpaks are the solution to address the cases you listed for the desktop user.

That sounds reasonable too, but I have to ask one question. Is there a tendency to switch to Flatpak for desktop applications and drop the RPM packaging for such apps in the future? My advocacy was based on the fact, that you want to consume RPM content for everything as it has been common so far.

For server users, the reality is that the overwhelming majority of users use a separate VM or container for every application (for resource management and isolation), so the Module approach is a perfect one for those cases.

Yes, I agree. If somebody wants to deploy a container quickly, modules indeed can help them.

Personally, I do not see a problem to experiment with anything you need in the ELN space, but I would suggest that ELN has a policy different from the main Fedora now and when the problems are solved we can adopt the ELN policy for the main Fedora then. Or change it to suit our needs.

Thanks for explanations.

4) @lruzicka You have defined a set of requirements that non-modular Fedora cannot possibly meet. Why do you think that modules should be held to that standard?
Non-modular RPMs still have Conflicts: that can result in preventing a subset of the OS to be uninstallable if you choose to pull them in.

Hello @sgallagh , you have made a fair point here, however, so far I have only experienced conflicts between packages that provide similar content, such as a library for instance. Usually, choosing one of the providing packages does not exclude other applications from being installed and if something like that happened, I would consider it "a bug."

Yes, that's honestly the same experience we expect from Modularity. People have interpreted this statement as meaning more than that. I don't really know why... possibly just because we called it out explicitly as a conscious decision we made not to try to solve that case.

In designing Modularity, we had to weigh the relative merits of the cases you just described and decide which tradeoffs to make. That said, Modules should not introduce conflicts when it can be avoided. I can put that in the policy if you like.

Yes, if you could do add it, we would have a clear policy on how to treat it in QE.

Sure, that's not a big deal. Conflicts may be unavoidable in some cases, but if they can be avoided, they really should be.

As far as desktop applications, we strongly recommend the use of Flatpaks for this case, rather than using Modularity directly (Flatpak uses modules behind the scenes to create their containers). Flatpaks are the solution to address the cases you listed for the desktop user.

That sounds reasonable too, but I have to ask one question. Is there a tendency to switch to Flatpak for desktop applications and drop the RPM packaging for such apps in the future? My advocacy was based on the fact, that you want to consume RPM content for everything as it has been common so far.

I think that's unrelated to this ticket. I have opinions here, but I think this is the wrong place to discuss them.

For server users, the reality is that the overwhelming majority of users use a separate VM or container for every application (for resource management and isolation), so the Module approach is a perfect one for those cases.

Yes, I agree. If somebody wants to deploy a container quickly, modules indeed can help them.
Personally, I do not see a problem to experiment with anything you need in the ELN space, but I would suggest that ELN has a policy different from the main Fedora now and when the problems are solved we can adopt the ELN policy for the main Fedora then. Or change it to suit our needs.
Thanks for explanations.

Thanks for reading them with an open mind. I appreciate it.

FESCo (mostly @churchyard) asserted that ELN may not play with default streams until and unless "Fedora" has a policy.

My opinions are:

• Fedora policy should be "no default streams"
• ELN should follow the policy

"Fedora" might decide that my opinions are not the best ones. For example, it may decide that "no default streams" is not a good policy for Fedora. In that case I would still say that ELN should follow the Fedora-approved policy (whatever it would be). Alternatively, Fedora may decide that "no default streams" is a good policy, but that ELN can have default streams. If either is the case, I will respect the decision.

So as long as this is proposed for "Fedora", I'd argue that "no default policy" is a better one.
If this is proposed for ELN only, I'd argue we shall not have a separate policy for ELN, if ELN remains to be "Fedora". I respect that this is something you don't agree with.

My first pass through this, I think most of it looks okay. The thing that stood out to me was this allowance of buildonly (aka build-time only) content. For Fedora in any form, this must not be allowed.

Considering this policy does not only cover default modular streams, but also other cases, I'd also like to suggest that modular packages should only be maintained by their explicit (co-)maintainers. E.g. I wouldn't like provenpackagers to use their provenpackager rights to branch packages and include them into their module without first getting an ack of the current (co-)maintainers.

My first pass through this, I think most of it looks okay. The thing that stood out to me was this allowance of buildonly (aka build-time only) content. For Fedora in any form, this must not be allowed.

Can you explain why you feel this must not be allowed? Your phrasing here suggests that it should be self-explanatory, but it's... not.

Any content marked as buildonly must still be present in Fedora's dist-git in a reachable commit, so we will still be distributing the source and can reproduce the behavior. If you want me to adjust the policy to something more like the old bundling policy where it requires FPC approval alongside a timeframe to get the package using the distro-provided dependency, then that's something we could consider.

If I'm missing some other issue, please illuminate me.

Considering this policy does not only cover default modular streams, but also other cases, I'd also like to suggest that modular packages should only be maintained by their explicit (co-)maintainers. E.g. I wouldn't like provenpackagers to use their provenpackager rights to branch packages and include them into their module without first getting an ack of the current (co-)maintainers.

I can write it out explicitly, but I think that's just an extension of the existing provenpackager expectations. They can provide fixes and rebuild if there's an urgent bug or to fix an FTBFS or other mass-adjustment to packages, but if they want to actually include a package in a module stream they are creating, they need to be a maintainer of it.

I'm not sure it would be worth the effort to make this a technical restriction, but we can certainly make it part of the policy.

My first pass through this, I think most of it looks okay. The thing that stood out to me was this allowance of buildonly (aka build-time only) content. For Fedora in any form, this must not be allowed.

Can you explain why you feel this must not be allowed? Your phrasing here suggests that it should be self-explanatory, but it's... not.
Any content marked as buildonly must still be present in Fedora's dist-git in a reachable commit, so we will still be distributing the source and can reproduce the behavior. If you want me to adjust the policy to something more like the old bundling policy where it requires FPC approval alongside a timeframe to get the package using the distro-provided dependency, then that's something we could consider.
If I'm missing some other issue, please illuminate me.

No, I think you hit the nail on the head. The adjustments you proposed there would make me happier with it. I don't want us to be in a situation where we have unsharable content. There are definitely scenarios where it might be necessary for some reason or another, but I don't want there to be a case where we have stuff in dist-git that isn't available to people in the repositories in some form.

Considering this policy does not only cover default modular streams, but also other cases, I'd also like to suggest that modular packages should only be maintained by their explicit (co-)maintainers. E.g. I wouldn't like provenpackagers to use their provenpackager rights to branch packages and include them into their module without first getting an ack of the current (co-)maintainers.

I can write it out explicitly, but I think that's just an extension of the existing provenpackager expectations. They can provide fixes and rebuild if there's an urgent bug or to fix an FTBFS or other mass-adjustment to packages, but if they want to actually include a package in a module stream they are creating, they need to be a maintainer of it.

Since this is exactly what was not followed in Fedora when we had default modular streams, I'd rather have it said explicitly, yes. While it might be obvious to me or you, it apparently wasn't for others. Thanks.

I'm not sure it would be worth the effort to make this a technical restriction, but we can certainly make it part of the policy.

No (extra) technical limitation required. AFAIK we have a restriction in place when requesting branches now (because non-maintainers used to request epel branches).

Not fully related to this PR, but something that must be done (https://pagure.io/fesco/issue/2390#comment-658334) for me to say +1 for default streams in ELN:

• Any package that is built in default streams MUST use ref: master (to ensure that any fixes that are made for ELN go to Fedora first). I am not sure what should happen to ELN when fedora branches. Since it is supposed to be next version of RHEL, I am not sure if it will be switched to track f33 or f35... In that case, I can be convinced to use ref:f33.
• Maintainers of packages are are part of default streams SHOULD be (co-)maintainers for a package in Fedora (this implies that they must not abuse provenpackager privileges to commit changes).
• Packages from default streams MUST be self-contained: do not depend on any other non-default-stream modules, they MAY depend on other default streams of modules but MUST specify such dependency in a module metadata.
• Packages from default streams MUST NOT contain packages with the same name as in non-modular content of ELN: those should be either moved completely to modular packages or should be de-modularized. That also applies for buildonly packages where options are extended with making package a no-buildonly.
• Modules with default streams MUST NOT override any macro during the RPM build, neither they can use if 0%{?_module_build} or similar conditionals in RPM spec. This essentially allows us to de-modularize those package in case of failure without headache.
• RPMs in default streams MUST NOT conflict with each other or any non-modular RPMs, neither on the dependency level, nor on the filesystem level.
• Workflow with koji sidetags MUST be well-defined and implemented.
• ELN SIG MUST define goals of modularity in ELN (things that needs to be achieved) before F33 branching and the timeline (just some rough overview is fine). Basically which issues are planned to be fixed, which features needs to be implemented and such. And of course keep the doc updated over the time. And have contingency plan. Prety much as you would do for a change proposal. Pretty sure this won't be easy, but I think we must do this in order to know what is happening in ELN and be aware of the plans. Otherwise we just end up with some RHEL playground in Fedora and not what ELN claims to be (Fedora and RHEL people cooperating on next RHEL release). That MUST include automation of any checks and anything that is necessary to make rebuilds painless when both non-modular and modular worlds are in play. That MUST be better than status quo with the RPMs. This is subject for FESCo approval.
• The ELN SIG is responsible to keep track of following these rules either manually (which would be the case as of now I believe) or by writing tooling.
• The ELN SIG is responsible to rebuild non-modular packages after SONAME changes in default streams (or with any other activity that would require package rebuild).
• The ELN SIG is responsible to rebuild default module streams after SONAME changes in non-modular content (or with any other activity that would require package rebuild).
• The ELN SIG is responsible to make conversion to non-modular RPMs if goals can't be met within specified timeline.

What happens to an RPM in a module that is marked buildonly now but a contributor in Fedora later wants to add it as a regular package? The package in question would exist in dist-git, right? Would that be a conflict?

contributor in Fedora later wants to add it as a regular package?

The package should already be non-modular in Fedora, no? Or the contributor wants to have package properly in ELN, that is non-buildonly?

RPMs in default streams MUST NOT conflict with each other or any non-modular RPMs, neither on the dependency level, nor on the filesystem level.

This rule is stronger than the non-modular rule. I don't consider that fair.

Workflow with koji sidetags MUST be well-defined and implemented.

What workflow?

Sorry, just getting back to this.

Not fully related to this PR, but something that must be done (https://pagure.io/fesco/issue/2390#comment-658334) for me to say +1 for default streams in ELN:

Any package that is built in default streams MUST use ref: master (to ensure that any fixes that are made for ELN go to Fedora first). I am not sure what should happen to ELN when fedora branches. Since it is supposed to be next version of RHEL, I am not sure if it will be switched to track f33 or f35... In that case, I can be convinced to use ref:f33.

I disagree with this, but that's mostly because I'm working on stronger assurances that ELN module contents appear first in Rawhide. Specifically, I'm looking to extend the module stream expansion feature of MBS such that we can tell it to build for ELN whenever we build for Rawhide (and disallow building for ELN independently).

In other words, a modulemd specifying

buildrequires:
  platform: []

would expand to [f31, f32, f33, eln, epel8]

and

buildrequires:
  platform: [ f33 ]

would expand to [ f33, eln ]

And we would prohibit the explicit inclusion of eln, so no one can build JUST for ELN. Thus, no code could be built for ELN that was not also offered in a module for Rawhide.

Maintainers of packages are are part of default streams SHOULD be (co-)maintainers for a package in Fedora (this implies that they must not abuse provenpackager privileges to commit changes).

I'm actually in favor of a stronger rule: A module stream maintainer MUST be a [co-]maintainer of every package included in the stream.

I agree that we don't want people using modules as a means to bypass the usual maintainership processes. Moreover, I want it to be clear that it's being packaged by someone familiar with the package.

Packages from default streams MUST be self-contained: do not depend on any other non-default-stream modules, they MAY depend on other default streams of modules but MUST specify such dependency in a module metadata.

I think this is reasonable.

Packages from default streams MUST NOT contain packages with the same name as in non-modular content of ELN: those should be either moved completely to modular packages or should be de-modularized.

I'm going to rephrase this part, because I think I understand you, but it's confusing.

If a package is to be included in a default stream, it MUST NOT shadow a package of the same name in the non-default stream (except in cases of migration of a package from non-modular to modular).

That also applies for buildonly packages where options are extended with making package a no-buildonly.

I don't understand what this part means. Would you mind rephrasing it?

Modules with default streams MUST NOT override any macro during the RPM build, neither they can use if 0%{?_module_build} or similar conditionals in RPM spec. This essentially allows us to de-modularize those package in case of failure without headache.

I think you're asking for us to disallow the use of the data.buildopts.rpm.macros section. I think that's probably acceptable, but I'll ask @psabata to weigh in on it.

RPMs in default streams MUST NOT conflict with each other or any non-modular RPMs, neither on the dependency level, nor on the filesystem level.

This is stricter than non-modular RPMs are required to be. Can we settle for "conflicts must be avoided where possible or else explicitly defined in the RPM spec using Conflicts:"?

Workflow with koji sidetags MUST be well-defined and implemented.

I'm not sure there's anything specific that needs to be done here. What did you envision?

ELN SIG MUST define goals of modularity in ELN (things that needs to be achieved) before F33 branching and the timeline (just some rough overview is fine). Basically which issues are planned to be fixed, which features needs to be implemented and such. And of course keep the doc updated over the time. And have contingency plan. Prety much as you would do for a change proposal. Pretty sure this won't be easy, but I think we must do this in order to know what is happening in ELN and be aware of the plans. Otherwise we just end up with some RHEL playground in Fedora and not what ELN claims to be (Fedora and RHEL people cooperating on next RHEL release). That MUST include automation of any checks and anything that is necessary to make rebuilds painless when both non-modular and modular worlds are in play. That MUST be better than status quo with the RPMs. This is subject for FESCo approval.

The goals of modularity in ELN for F33 are "successfully build a selection of modules that are available from Rawhide". I'm not sure what you need as a contingency plan; we'd just turn off the stream expansion for ELN.

The ELN SIG is responsible to keep track of following these rules either manually (which would be the case as of now I believe) or by writing tooling.

Agreed.

The ELN SIG is responsible to rebuild non-modular packages after SONAME changes in default streams (or with any other activity that would require package rebuild).

Agreed.

The ELN SIG is responsible to rebuild default module streams after SONAME changes in non-modular content (or with any other activity that would require package rebuild).

This shouldn't be needed, since the maintainer of the package bumping SONAME is presumably responsible for rebuilding the module in Rawhide which will implicitly rebuild it in ELN.

The ELN SIG is responsible to make conversion to non-modular RPMs if goals can't be met within specified timeline.

This shouldn't be difficult, as it should just mean rebuilding from Rawhide.

What happens to an RPM in a module that is marked buildonly now but a contributor in Fedora later wants to add it as a regular package? The package in question would exist in dist-git, right? Would that be a conflict?

Nothing can be built in a module without having a component in dist-git, which means that someone had to go through the new-package-process already. If they opted not to build it for Fedora/EPEL as well and someone comes along and wants to do that, they'd need to be added as a comaintainer through the usual processes.

This shouldn't be needed, since the maintainer of the package bumping SONAME is presumably responsible for rebuilding the module in Rawhide which will implicitly rebuild it in ELN.

That is however not realistic. The packager who bumps the SONAME does not even know what modular content depends on their package (unless told explicitly).

This shouldn't be needed, since the maintainer of the package bumping SONAME is presumably responsible for rebuilding the module in Rawhide which will implicitly rebuild it in ELN.

That is however not realistic. The packager who bumps the SONAME does not even know what modular content depends on their package (unless told explicitly).

That honestly sounds like a different problem: lack of easy discoverability. The same tools they use to find non-modular content that depends on their package should be usable to discover the modular content.

Yes, see https://pagure.io/modularity/issue/165

Yes, see https://pagure.io/modularity/issue/165

Yeah, that fell off my radar. I've revived that ticket. Thanks.

If a package is to be included in a default stream, it MUST NOT shadow a package of the same name in the non-default stream (except in cases of migration of a package from non-modular to modular).

That also applies for buildonly packages where options are extended with making package a no-buildonly.

I don't understand what this part means. Would you mind rephrasing it?

That basically means, if Cython is a non-modular RPM, it should not be used as buildonly package in any default modular stream. It either have to be used as buildonly exclusively, be a non-modular RPM or modular RPM from default stream.

RPMs in default streams MUST NOT conflict with each other or any non-modular RPMs, neither on the dependency level, nor on the filesystem level.

This is stricter than non-modular RPMs are required to be. Can we settle for "conflicts must be avoided where possible or else explicitly defined in the RPM spec using Conflicts:"?

I think I was too strict with it, but I was not sure how to phrase it. But I think I would be fine if conflicts are properly defined in RPMs. Also keep in mind that we have guidelines around that and packagers are supposed to follow them: https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/

I think you're asking for us to disallow the use of the data.buildopts.rpm.macros section. I think that's probably acceptable, but I'll ask @psabata to weigh in on it.

Basically yes. And also disallow using %_module_build in spec files.

Workflow with koji sidetags MUST be well-defined and implemented.

I'm not sure there's anything specific that needs to be done here. What did you envision?

I don't know all details about default streams in the buildroot, but what I meant is that if I bump SONAME of some lib, I create side tag, build all non-modular things there. I suppose that I can't get there any modular builds, so once I merge side tag, the modular builds will be broken. So what I am asking is the plan how to make sidetags work with modules so that we can do breaking updates and ship them "as one unit".

The goals of modularity in ELN for F33 are "successfully build a selection of modules that are available from Rawhide". I'm not sure what you need as a contingency plan; we'd just turn off the stream expansion for ELN.

Exactly like that, it is not complete. Just turning off default modular streams and stream expansion will not magically demodularize packages so that ELN would be same as today.

This shouldn't be needed, since the maintainer of the package bumping SONAME is presumably responsible for rebuilding the module in Rawhide which will implicitly rebuild it in ELN.

That is not true. Packagers are not responsible for rebuilding any modular content on a SONAME change. Module maintainers are.

This shouldn't be difficult, as it should just mean rebuilding from Rawhide.

Easy to say, but in reality pretty sure you will hit some problems :)

One requirement I forgot to add is:

• Default module streams MUST NOT use any non-default module streams in the buildrequires.

I disagree with this, but that's mostly because I'm working on stronger assurances that ELN module contents appear first in Rawhide. Specifically, I'm looking to extend the module stream expansion feature of MBS such that we can tell it to build for ELN whenever we build for Rawhide (and disallow building for ELN independently).
In other words, a modulemd specifying
buildrequires:
platform: []

would expand to [f31, f32, f33, eln, epel8]
and
buildrequires:
platform: [ f33 ]

would expand to [ f33, eln ]
And we would prohibit the explicit inclusion of eln, so no one can build JUST for ELN. Thus, no code could be built for ELN that was not also offered in a module for Rawhide.

Sorry for the confusion, but this is actually wrong. I was working from old notes.

The actual intended behavior is that the ELN SIG will set up automation to rebuild specific Rawhide module streams in ELN (overriding the platform: requirement).

The effect for Fedora is the same: people must work in Rawhide and cannot build specifically for ELN, bypassing Fedora.

That basically means, if Cython is a non-modular RPM, it should not be used as buildonly package in any default modular stream. It either have to be used as buildonly exclusively, be a non-modular RPM or modular RPM from default stream.

Ah, I think I understand what you're asking for. You want us to ensure that default streams that have a dependency on something that exists in the non-modular repository must not build against a private version that may have a different configuration.

I disagree with that. I'm open to requiring that to be approved somewhere, but I think there are cases where it would make sense. For example, a package in ELN might want to carry a patched version of a docs-generating package as buildonly.

I think the rule we want to establish is this: using buildonly: in a default stream MUST NOT result in an incompatibility between the modular contents and the non-modular version of that same package. So, we can't build against a library with extra features and try to run it against the non-modular library that doesn't have them. The reverse may be acceptable though: linking against a buildonly library that is a proper subset of the non-modular library. As long as there is no ABI-breakage, it may be desirable for the modular content to use a more-restrictive link.

RPMs in default streams MUST NOT conflict with each other or any non-modular RPMs, neither on the dependency level, nor on the filesystem level.

This is stricter than non-modular RPMs are required to be. Can we settle for "conflicts must be avoided where possible or else explicitly defined in the RPM spec using Conflicts:"?

I think I was too strict with it, but I was not sure how to phrase it. But I think I would be fine if conflicts are properly defined in RPMs. Also keep in mind that we have guidelines around that and packagers are supposed to follow them: https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/

Let's go with "All RPMs in default module streams are required to conform to the same requirements around Conflicts as non-modular RPMs.

I think you're asking for us to disallow the use of the data.buildopts.rpm.macros section. I think that's probably acceptable, but I'll ask @psabata to weigh in on it.

Basically yes. And also disallow using %_module_build in spec files.

I think that's probably reasonable.

Workflow with koji sidetags MUST be well-defined and implemented.

I'm not sure there's anything specific that needs to be done here. What did you envision?

I don't know all details about default streams in the buildroot, but what I meant is that if I bump SONAME of some lib, I create side tag, build all non-modular things there. I suppose that I can't get there any modular builds, so once I merge side tag, the modular builds will be broken. So what I am asking is the plan how to make sidetags work with modules so that we can do breaking updates and ship them "as one unit".

We are going to work on this support in MBS. @bookwar has more information on this.

The goals of modularity in ELN for F33 are "successfully build a selection of modules that are available from Rawhide". I'm not sure what you need as a contingency plan; we'd just turn off the stream expansion for ELN.

As noted in a previous comment, we're actually not doing the stream expansion.

Exactly like that, it is not complete. Just turning off default modular streams and stream expansion will not magically demodularize packages so that ELN would be same as today.

One option would be to relax our earlier requirement on not allowing ELN default module streams to shadow the non-modular ones. If we allow the non-modular ones to be built and require that the default streams' version must be built from the same git commit, then we can just disable the module default streams and the non-modular one would reappear. (Though if you already had the modular one installed, it gets trickier).

I'm not sure a contingency plan needs to be too thorough for ELN at this point, though. If things aren't working in ELN... it's a prototype. We can scrap it without affecting Fedora.

This shouldn't be needed, since the maintainer of the package bumping SONAME is presumably responsible for rebuilding the module in Rawhide which will implicitly rebuild it in ELN.

That is not true. Packagers are not responsible for rebuilding any modular content on a SONAME change. Module maintainers are.

That is not an established rule. I think module maintainers should be responsible for keeping an eye out for SONAME bumps that might affect them, but I think it's also reasonable for the dependency owner to include module streams in their due-diligence investigation.

ELN-SIG can commit to providing documentation on how to discover this, though.

This shouldn't be difficult, as it should just mean rebuilding from Rawhide.

Easy to say, but in reality pretty sure you will hit some problems :)

Yeah, yeah. Theory != practice.

One requirement I forgot to add is:

Default module streams MUST NOT use any non-default module streams in the buildrequires.

I'm not sure this is strictly necessary. If it doesn't change the runtime requirements, why does it matter?

Sorry for the confusion, but this is actually wrong. I was working from old notes.

ack

I've just updated the PR and the preview. I think I incorporated all of the feedback I've gotten so far on this ticket.

In general, this looks good, but I am uncertain about the criteria for allowing buildonly: components. We're exclusively using this to build something that we only need at build-time, but what are the conditions in which this is okay to do? I don't want this to be used as a mechanism for packages to get shoved into Dist-Git and not be maintained or available anywhere for people to consume. We should default to open, and even includes what stuff we use to build stuff. :wink:

From my perspective, the only case that makes sense to me as a build-only thing is if something was in Fedora and is no longer, but is required for building something and doesn't leak any kind of run-time dependency. The example of an old version of sphinx or doxygen is a good one, IMO. I'm not sure there are any other cases that this should ever be allowed.

Packages MAY convert from a non-modular package to a modular default stream (or the reverse) within a Fedora release, provided that the modular default and non-modular versions are version, API and ABI identical.

How does this technically work when converting from modular to non-modular and the default modular stream is part of the GA modular repo? IIRC previously we had problems regarding this -- once the default modular stream was visible for dnf, it was impossible to "demodularize". Is this any different nowadays?

In general, this looks good, but I am uncertain about the criteria for allowing buildonly: components. We're exclusively using this to build something that we only need at build-time, but what are the conditions in which this is okay to do? I don't want this to be used as a mechanism for packages to get shoved into Dist-Git and not be maintained or available anywhere for people to consume. We should default to open, and even includes what stuff we use to build stuff. 😉

I think this situation is actually still an improvement over the current state of things in Fedora. There are a lot of packages in non-modular Fedora today that are minimally-maintained because the person who brought it into the distro only cared about it insofar as it was a dependency of the package they actually needed.

Allowing modules to define buildonly content allows us to have a view into that; if someone else comes along and wants to maintain that component properly, they can pull it into non-modular Fedora and then coordinate with the module maintainer to drop their private copy. Now it's in Fedora and is maintained by someone who actually cares about it.

The example of an old version of sphinx or doxygen is a good one, IMO.

Honestly, I don't consider the sphinx example that good. We should still prefer a compat package even if it explicitly conflicts with the "mainline" one, similarly how we've done recently with python-pytest4.

How does this technically work when converting from modular to non-modular and the default modular stream is part of the GA modular repo? IIRC previously we had problems regarding this -- once the default modular stream was visible for dnf, it was impossible to "demodularize". Is this any different nowadays?

https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL has this covered. The new modulemd-eol document allows us to designate a stream for "reset". Coupled with removing the default from the modulemd-defaults document means that the non-modular package will again be visible.

https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL has this covered. The new modulemd-eol document allows us to designate a stream for "reset". Coupled with removing the default from the modulemd-defaults document means that the non-modular package will again be visible.

Actually, it's possible I'm misreading that; @dmach can you confirm that the new Obsoletes handling addresses the demodularization case? And if not, can you please figure out how to make it do so?

As something of a hack, I suppose we could just mark the stream as being obsoleted by something like platform: [].

That Fedora change speaks about about system upgrade (i.e. upgrading from Fedora N to N+1 or N+2). The policy here speaks about changes within a Fedora release -- does that mean "changes in rawhide during one release cycle" or "changes in already released Fedora versions"?

That Fedora change speaks about about system upgrade (i.e. upgrading from Fedora N to N+1 or N+2). The policy here speaks about changes within a Fedora release -- does that mean "changes in rawhide during one release cycle" or "changes in already released Fedora versions"?

Sorry, can you provide more context? I'm not sure which part you're referring to, specifically.

Sure.

Packages MAY convert from a non-modular package to a modular default stream (or the reverse) within a Fedora release...

What does the emphasized part of the guideline refer to exactly?

Oh right, we should not permit modules to have a strict runtime dependency on the platform module. That is the core of what breaks upgrades.

https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL has this covered. The new modulemd-eol document allows us to designate a stream for "reset". Coupled with removing the default from the modulemd-defaults document means that the non-modular package will again be visible.

Actually, it's possible I'm misreading that; @dmach can you confirm that the new Obsoletes handling addresses the demodularization case? And if not, can you please figure out how to make it do so?
As something of a hack, I suppose we could just mark the stream as being obsoleted by something like platform: [].

The EOL/Obsoletes feature is designed only to reset or switch streams.
It doesn't hide or remove them from repos completely.
Resetting a stream should be enough for leeting non-modular RPMs appear again. As you suggested, removing the stream from defaults will be needed too.
Please note that this will happen only during a system upgrade or after explicitly running a new dnf command. There was certain pushback against applying EOL/Obsoletes automatically.

Oh right, we should not permit modules to have a strict runtime dependency on the platform module. That is the core of what breaks upgrades.

I'm glad you brought this topic.
My recommendation is to drop the explicit runtime dependency on platform.
Using $releasever is good enough in most cases while the platform dependency makes repoquery unusable and rawhide streams are not consumable from stable Fedora. This is a regression to the behavior known from rpm packages & non-modular repos. Dropping the platform dependency should fix that.

Sure.

Packages MAY convert from a non-modular package to a modular default stream (or the reverse) within a Fedora release...

What does the emphasized part of the guideline refer to exactly?

OK, I see the confusion. The part you emphasized is referring to converting between non-modular and default stream modular packages if and only if they are the same. So we'll allow you to make a non-modular package into a default stream (or the reverse) within a released Fedora as long as they follow the Stable Updates Policy (don't break any dependencies).

The default stream can only make significant changes with a Change Proposal for the next release. Does that clear it up? I'll try to make that more explicit in the policy.

Oh right, we should not permit modules to have a strict runtime dependency on the platform module. That is the core of what breaks upgrades.

I'm glad you brought this topic.
My recommendation is to drop the explicit runtime dependency on platform.
Using $releasever is good enough in most cases while the platform dependency makes repoquery unusable and rawhide streams are not consumable from stable Fedora. This is a regression to the behavior known from rpm packages & non-modular repos. Dropping the platform dependency should fix that.

I wish it was that simple...

Right now, we rely on the runtime platform stream to determine which streams to put into which repo when running the compose. If we switch to basing it on the build-time stream, we'll have problems with modules like maven which are built on a single platform but shipped on multiple. (In the case of Java, they generally build them on the oldest supported release and ship them on all releases.) This could probably be solved through tagging, but it's something we still need to address.

Also, we need to ensure that on upgrades from FN to FN+1 we switch to the stream built for that release. The NVR the module packages aren't guaranteed to be a higher on the next platform, so we'll have to be able to recognize that and deal with it. I think we're doing distro-sync on upgrades these days, so that may not be too much of an issue there, but I have no idea what exactly we'll need to do to make updates work for Rawhide at the Branch.

So we'll allow you to make a non-modular package into a default stream (or the reverse) within a released Fedora as long as they follow the Stable Updates Policy (don't break any dependencies).

I am quite confident that "or the reverse" is not technically possible. Hence I suggest we doesn't allow this either way. What's released as stable stays intact.

So we'll allow you to make a non-modular package into a default stream (or the reverse) within a released Fedora as long as they follow the Stable Updates Policy (don't break any dependencies).

I am quite confident that "or the reverse" is not technically possible. Hence I suggest we doesn't allow this either way. What's released as stable stays intact.

Your confidence does not change the fact that the DNF team just said it was planned.

@dmach explicitly said here:

Please note that this will happen only during a system upgrade or after explicitly running a new dnf command.

Hence I don't understand how is that planned. Could you please be more specific?

Ah, I see what you mean now. I suspect that's addressable, but I'm fine with making it be on distro-upgrade (or manually with a command for those on Rawhide).

My point is that I would only allow such changes on distro-upgrade boundary and in rawhide (possibly in branched pre-beta freeze fro planned changes and pre-final freeze for contingency plans), what's released as stable stays intact.

My point is that I would only allow such changes on distro-upgrade boundary and in rawhide (possibly in branched pre-beta freeze fro planned changes and pre-final freeze for contingency plans), what's released as stable stays intact.

I pushed a patch that covers that, I think. (I also updated the preview.)

I pushed a patch that covers that, I think.

It does. Presumably we would still be able to do emergency fixups in branched with FESCo approval, right?

I pushed a patch that covers that, I think.

It does. Presumably we would still be able to do emergency fixups in branched with FESCo approval, right?

I don't think that needs calling out, since FESCo can always override any implementation decision. But yes, that's fine.

The phrasing here gives the impression that this is the agreed
best way to handle the cases below. But (as we all know) people
have strongly differing opinions on this.

Applications with multiple supported, incompatible releases that rely on the same well-known names.footnote:
...
org.freedesktop.Accounts, DNS Server on port 53]

Those two examples are egregious. One of the core goals of D-Bus
is to have multiple co-installed(!) implementations for names.
That's why the whole dance with taking of names and releasing of
names and notifications about this to all other clients is done
every time a D-Bus client connects. The same is true for DNS and
other services which listen on a well-known port and implement an
established protocol. This particular port can be handled at
least by systemd-resolved, dnsmasq, bind, and knot in
Fedora, but I wouldn't be surprised if there was a dozen other
packages. Existing packaging mechanisms deal with such "well
known names" just fine and bringing modules which give
installation-time conflicts into this would be actively harmful.

[/usr/bin/node

This example is better. Nevertheless, there are at least two
other options: first, alternatives. Second, simply having
Conflicts between packages. This is allowed (although
discouraged) by the Packaging Guidelines. For the case of a
single binary, both approaches could be considered better for
users than modules. Alternatives are high-overhead and most
people don't like them for good reasons. But two Conflicting
packages are trivial to implement and the effect is similar to
module streams.

It would be worth mentioning those two other approaches in this
document, with a link to the appropriate docs elsewhere, so that
people can consider different options they have.

Packages with a stable and an experimental release.

This case is similar to the previous one. For a single binary,
a "compat package", even if it Conflicts with the main package,
works quite well. I think the example of a stack of packages
(e.g. node interpreter and some dependent packages) would be
more convincing.

Packages with a build-time-only dependency that would otherwise
conflict with the Fedora buildroot.footnote:[Example: a package
whose documentation is generated by an older version of
python-sphinx than is available in the current Fedora release]

Not a great example either. First, python-sphinx does
not "conflict with the Fedora buildroot". More generally, nothing
in normal packages and modular packages should ever conflict with
the buildroot. I guess you mean something like "a build-time-only
dependency that is in a different version than one current".
Python-sphinx is a bad example here too, since we're now
transitioning to sphinx 3.1.1 in rawhide and the plan is to
simply provide a compat package if necessary. Making sphinx
modular is way overkill for this simple transition. It would also
cascade to the slew of packages that use sphinx for documentation.
Maybe there's some realistic example?

Tightly-coupled packages that need to be rebuilt together.

We have chain-build and sidetags for this.

After going through all the cases above, none of the examples are
convincing. There are some places where modules may be the
reasonable answer. So for example, if you're building a stack of
co-dependent packages that don't express dependencies in a way
that would allow normal package requirements to be enough to pull
in packages from the stack instead of the alternative. If this
document is to provide a list at all, it should document cases
where modules can be argued to be a good solution, and it should
give semi-realistic examples.

I fully agree with @zbyszek. The cases listed in "Cases where modules should be strongly considered" are not convincing to me and the provided examples are questionable at least. For each of them another solution than modularity already exists, arguably much simpler. If this is to be promoted as the official list, I would not vote in favor (I guess you expected this already, but I wanted to be explicit here).

I've been reading the preview you post rather than the diff because it's easier. Here's what I have been reading from time to time:

https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/

Concerns/comments/questions:

1) Under "To Modularize or Not?" the language is weighted heavily towards pro-module. Since this is a policy document, I would prefer the language be more neutral and not convey an opinion of pro or anti anything. The policy should provide the information. Specifically, language like "strongly considered". The information is provided, I would feel more comfortable with a neutral tone.

2) For each point under "Requirements for All Module Streams", an explanation for each requirement would be useful. Contributors may naturally ask why they need explicit commit privileges on each component. This document could help guide the reader.

3) "All packages provided at runtime by the default stream of a module MUST provide all the same functionality that a downstream consumer would expect from a package in the non-modular package set." is subjective. What constitutes same functionality and how can that be verified? What does the downstream consumer expect? Can those expectations be collected in some way so that modular and non-modular packages can be tested? I know this question is getting out of the scope of a policy document, but with regard to policy do we have a line for what we consider expected functionality?

I otherwise like the new draft. Thanks, @sgallagh, for working on this.

I've been reading the preview you post rather than the diff because it's easier. Here's what I have been reading from time to time:
https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/
Concerns/comments/questions:
1) Under "To Modularize or Not?" the language is weighted heavily towards pro-module. Since this is a policy document, I would prefer the language be more neutral and not convey an opinion of pro or anti anything. The policy should provide the information. Specifically, language like "strongly considered". The information is provided, I would feel more comfortable with a neutral tone.

We discussed this at today's FESCo meeting and decided to strike this section from the draft entirely and revisit it as a separate effort.

2) For each point under "Requirements for All Module Streams", an explanation for each requirement would be useful. Contributors may naturally ask why they need explicit commit privileges on each component. This document could help guide the reader.

Yeah, that's not unreasonable. I'll add details to anything non-obvious.

3) "All packages provided at runtime by the default stream of a module MUST provide all the same functionality that a downstream consumer would expect from a package in the non-modular package set." is subjective. What constitutes same functionality and how can that be verified? What does the downstream consumer expect? Can those expectations be collected in some way so that modular and non-modular packages can be tested? I know this question is getting out of the scope of a policy document, but with regard to policy do we have a line for what we consider expected functionality?

This is meant to specifically address the issues that the Maven module caused when it started shipping a vastly stripped-down version of a bunch of Java packages in a default stream.

I'm not sure how to frame it any better than this. Packages in default streams need to be maintained exactly the same way they are if it was a non-modular package (e.g. it has to be assumed that others will rely on it). This is definitely subjective and there's really no way around that.

I otherwise like the new draft. Thanks, @sgallagh, for working on this.

It has been an adventure, certainly. I think the outcome is proving it worthwhile though.

Added a commit with additional footnotes explaining the reasons behind the non-obvious rules. If this looks good to the reviewers, I'll submit it as a Change Proposal.

High level brainstorm:

The page is called "Policies Regarding Modules in Fedora and EPEL".

• Are there any EPEL specific rules we want here (maybe later, not now)?
• Should the Default Streams section have a huge warning box at the beginning that says that Default Streams are not allowed in Fedora, but are allowed in EPEL (and possibly ELN if/when that happens)?

Low level brainstorm:

Multiple default streams MUST NOT provide the same binary package names at runtime.

Does this (only) mean they cannot have "binary RPMs" with the same name or that they cannot "provide the same name"? As an example, obviously, we cannot have python3-pytest version 4 and python3-pytest version 5 in different default modular streams. However if we have python3-pytest4, can it provide python3-pytest? In other words, the phrase provide the same binary package names is hard to parse for me.

I submitted the Change Proposal as requested: https://fedoraproject.org/wiki/Changes/ModularPolicy

High level brainstorm:
The page is called "Policies Regarding Modules in Fedora and EPEL".

Are there any EPEL specific rules we want here (maybe later, not now)?

Probably yes. At minimum we need to note that there cannot be any module:stream overlap with RHEL.

Should the Default Streams section have a huge warning box at the beginning that says that Default Streams are not allowed in Fedora, but are allowed in EPEL (and possibly ELN if/when that happens)?

They're actually not allowed in EPEL 8 either. I think we're probably okay as-is though, as all changes to defaults require FESCo approval via the Change Process.

Low level brainstorm:

Multiple default streams MUST NOT provide the same binary package names at runtime.

Does this (only) mean they cannot have "binary RPMs" with the same name or that they cannot "provide the same name"? As an example, obviously, we cannot have python3-pytest version 4 and python3-pytest version 5 in different default modular streams. However if we have python3-pytest4, can it provide python3-pytest? In other words, the phrase provide the same binary package names is hard to parse for me.

It means they cannot have Provides: name in the RPM metadata, but I didn't think that would be clear enough in this. I'm open to a suggestion for a better (understandable) phrasing.

They're actually not allowed in EPEL 8 either. I think we're probably okay as-is though, as all changes to defaults require FESCo approval via the Change Process.

I disagree. Default streams are not allowed in Fedora, not allowed in EPEL 8, technically not yet allowed in ELN. With the current policy proposal and the change proposal I do not understand the intention of the policy + change. Is the intention to:

1. Keep the status quo and not allow default modular streams? If so, the policy for default modular streams is meaningless.
2. Allow default modular streams in Fedora generally? If so, the change proposal should be System Wide and mention this more explicitly. It should also have a defined contingency plan.
3. Allow default modular streams in ELN only? If so, the change proposal or the policy proposal should mention this explicitly.

It means they cannot have Provides: name in the RPM metadata, but I didn't think that would be clear enough in this. I'm open to a suggestion for a better (understandable) phrasing.

Maybe I still don't understand this properly. For example, if binary package pkg1 from a default modular stream m1:s1 has:

Provides: pkg = 1.5-8

And binary package pkg2 from a default modular stream m2:s2 has:

Provides: pkg = 2.4-1

That would be against this rule? If that is the intention, such rule is stronger than non-modular rules. E.g. we can have python2.7 and python3.9 packages both providing python(abi) in non-modular Fedora, but we would not allow this if the packages come from different default streams (like in RHEL 8)?

@sgallagh Stripping capabilities during a modular build is impossible to enforce. I think it's fine if modular packages provide the same capabilities as non-modular ones as long as they aren't mutated from normal package builds using buildopts or similar...

High-level questions:

What @churchyard said:

Default streams are not allowed in Fedora, not allowed in EPEL 8, technically not yet allowed in ELN. With the current policy proposal and the change proposal I do not understand the intention of the policy + change. Is the intention to:

Yes, without an answer to this, it's hard to form any opinions about this proposal.

What is the relationship of this document to other documents? Is it self-contained? If not, what other documents are incorporated and how? I don't think it is sufficient to have three one-sentence rules to describe something as complicated as modules.

Some low-level questions:

• Components built into a module MUST be associated with a reachable commit in Fedora dist-git.footnote:[There are legal and licensing requirements for reproducibility of builds.]

I thought this would be enforced by koji / mbs. Is there any reason to form this into a rule? (Incidentally removing this would live us with two rules for modules.)

If a stream of a module has build-time-only components, all such components MUST be marked as buildonly: True in the module metadata to avoid shipping them to users and polluting their repository.

Isn't this backwards? As @kkofler argued multiple times, build-only rpms are evil []. So I'd expect a rule to say that buildonly:True may* be used if the rpm is not suitable for exporting for some reason, and also mention that this should be avoided, and list cases where this makes sense and is allowed.

[*] evil ~ destructive to the community of packagers

@sgallagh Stripping capabilities during a modular build is impossible to enforce. I think it's fine if modular packages provide the same capabilities as non-modular ones as long as they aren't mutated from normal package builds using buildopts or similar...

I can't figure out what part of the policy you're referring to here.

High-level questions:
What @churchyard said:

Default streams are not allowed in Fedora, not allowed in EPEL 8, technically not yet allowed in ELN. With the current policy proposal and the change proposal I do not understand the intention of the policy + change. Is the intention to:

I answered this on the fedora-devel list. I'm going to add a note at the top regarding the status of default streams for Fedora, EPEL and ELN.

Yes, without an answer to this, it's hard to form any opinions about this proposal.
What is the relationship of this document to other documents? Is it self-contained? If not, what other documents are incorporated and how? I don't think it is sufficient to have three one-sentence rules to describe something as complicated as modules.

It is not self-contained. It addresses only the high-level policies. Anything under the "Policies" heading in the contents bar is also policy (and will be updated as we go).

Some low-level questions:

Components built into a module MUST be associated with a reachable commit in Fedora dist-git.footnote:[There are legal and licensing requirements for reproducibility of builds.]

I thought this would be enforced by koji / mbs. Is there any reason to form this into a rule? (Incidentally removing this would live us with two rules for modules.)

The modulemd specification allows for it to look elsewhere for the commits.

We are enforcing this rule in Koji and MBS already, but it's useful to have it listed explicitly for future reference.

If a stream of a module has build-time-only components, all such components MUST be marked as buildonly: True in the module metadata to avoid shipping them to users and polluting their repository.

Isn't this backwards? As @kkofler argued multiple times, build-only rpms are evil []. So I'd expect a rule to say that buildonly:True may be used if the rpm is not suitable for exporting for some reason, and also mention that this should be avoided, and list cases where this makes sense and is allowed.
[] evil ~ destructive to the community of packagers

Perhaps I should add another rule above this:

• Modules MAY use build-time-only components if delivering them into the repository would result in a significant negative user-experience (such as unnecessarily replacing a popular package with an older or newer version).

Would that help make it clearer?

High-level questions:
What @churchyard said:
Default streams are not allowed in Fedora, not allowed in EPEL 8, technically not yet allowed in ELN. With the current policy proposal and the change proposal I do not understand the intention of the policy + change. Is the intention to:

I answered this on the fedora-devel list. I'm going to add a note at the top regarding the status of default streams for Fedora, EPEL and ELN.

I read the discussion, but I'd still like to have a clearer answer. If this Change is supposed to allow default streams (where?) then I would expect this to be in the title and prominently mentioned in the summary and in the text of the change page. If it's not, then I'd expect a note in the Change page why the majority of the PR is about default streams.

Yes, without an answer to this, it's hard to form any opinions about this proposal.
What is the relationship of this document to other documents? Is it self-contained? If not, what other documents are incorporated and how? I don't think it is sufficient to have three one-sentence rules to describe something as complicated as modules.

It is not self-contained. It addresses only the high-level policies. Anything under the "Policies" heading in the contents bar is also policy (and will be updated as we go).

I see "Packaging Policy" and "Naming Policy" there. So for example nothing about lifetimes of modules. That's why I'm asking if there are other documents.

Some low-level questions:
Components built into a module MUST be associated with a reachable commit in Fedora dist-git.footnote:[There are legal and licensing requirements for reproducibility of builds.]
I thought this would be enforced by koji / mbs. Is there any reason to form this into a rule? (Incidentally removing this would live us with two rules for modules.)

The modulemd specification allows for it to look elsewhere for the commits.
We are enforcing this rule in Koji and MBS already, but it's useful to have it listed explicitly for future reference.

OK.

If a stream of a module has build-time-only components, all such components MUST be marked as buildonly: True in the module metadata to avoid shipping them to users and polluting their repository.
Isn't this backwards? As @kkofler argued multiple times, build-only rpms are evil []. So I'd expect a rule to say that buildonly:True may be used if the rpm is not suitable for exporting for some reason, and also mention that this should be avoided, and list cases where this makes sense and is allowed.
[] evil ~ destructive to the community of packagers

Perhaps I should add another rule above this:

Modules MAY use build-time-only components if delivering them into the repository would result in a significant negative user-experience (such as unnecessarily replacing a popular package with an older or newer version).

Would that help make it clearer?

Yep, it would.

Note: https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/packaging-guidelines/#_short_overview lists what is allowed, and buildonly doesn't seem to be mentioned there as allowed.

@sgallagh Stripping capabilities during a modular build is impossible to enforce. I think it's fine if modular packages provide the same capabilities as non-modular ones as long as they aren't mutated from normal package builds using buildopts or similar...

I can't figure out what part of the policy you're referring to here.

I'm referring to your statement about Provides.

I read the discussion, but I'd still like to have a clearer answer. If this Change is supposed to allow default streams (where?) then I would expect this to be in the title and prominently mentioned in the summary and in the text of the change page. If it's not, then I'd expect a note in the Change page why the majority of the PR is about default streams.

I'm incorporating this into my next update. It will state clearly "Default streams are not permitted in Fedora or EPEL 8. Fedora ELN permits defaults streams that adhere to the policy below. "

I see "Packaging Policy" and "Naming Policy" there. So for example nothing about lifetimes of modules. That's why I'm asking if there are other documents.

There will be other documents, but those are out of scope for this PR. The new Modularity Team is working on this.

Perhaps I should add another rule above this:

Modules MAY use build-time-only components if delivering them into the repository would result in a significant negative user-experience (such as unnecessarily replacing a popular package with an older or newer version).

Would that help make it clearer?

Yep, it would.

Will do.

Note: https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/packaging-guidelines/#_short_overview lists what is allowed, and buildonly doesn't seem to be mentioned there as allowed.

You are correct, that page is out of date. The buildonly directive is essentially a more flexible version of filter. Currently you can manually list all of the produced binary RPMs in filter, but buildonly handles that automatically for components that should not be shipped.

@sgallagh Stripping capabilities during a modular build is impossible to enforce. I think it's fine if modular packages provide the same capabilities as non-modular ones as long as they aren't mutated from normal package builds using buildopts or similar...

I can't figure out what part of the policy you're referring to here.

I'm referring to your statement about Provides.

OK, I finally figured out what you meant here. it's actually not impossible to change Provides: in a module build; you just have to build the affected RPM from a different branch. But that's a side-note.

I was originally attempting to prevent any ambiguity, but I realize that for virtual Provides:, that's likely impossible. Essentially, this probably just falls back to the catch-all (but not encodable as policy) of "RPMs in a default stream must behave to the user identically to non-modular packages". So if they have virtual Provides: such that they can provide equivalent content to a non-modular package (e.g. Provides: http), they should be resolved the same as if they weren't coming from a module.

Other than that, the main reason to avoid using the same binary package name is because of modular RPM shadowing. I'm going to try and rephrase this better.

Alright, new version pushed and preview available at https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/

I made one additional modification to make it clearer that Default Streams are ELN-only (I added "in Fedora ELN" to the section header and bolded the note about Fedora and EPEL disallowing them).

Can we get this merged now? FESCo approved the related Change in https://pagure.io/fesco/issue/2452

@zbyszek Does this most recent change satisfy your concerns about the target of the default stream policy?

:thumbsup:

Yes, thank you.