On Fri, Aug 03, 2018 at 04:43:15PM +0200, Miro Hrončok wrote:
> Hi,
>
> I was thinking about this for a while and I got the impression that this is
> something I don't know the answer for. The question is a bit harder to
> formulate simply, so let put it in examples:
I see no one's really responded to this yet (ack!), so let me try...
> a) A need packaging guideline is about to be discussed. A member of FPC
> wants to know how many packages would be affected so they run a quick grep
> query over all the rawhide specfiles at [0].
Obviously this wouldn't be enough. We would need to find all
modules shipped with Rawhide, then all the RPM stream branches
they build from, and grep those as well. Perhaps we could
do something to generate archives that include all of this
automatically.
Currently supported modules are tagged in the f*-modular* tags.
> b) A CVE is found in a web framework, so bugz are filled for the "framewrok"
> package to be fixed in Fedora 27, because newer Fedoras have newer version
> of the framework where the CVE is not applicable.
Also valid. Rather than just relying on the non-modular package
upgrade path, all currently supported modules and their RPMs
would need to be checked.
> c) A new version of interpreted language lands in rawhide. All packages
> depending on the interpeter need mass rebuild in a side tag.
This would be a new stream of the interpreter module.
Supposedly those packages would be also modularized? In that
case everything that builds against the interpreter module with
stream expansion would need to be "rebuilt".
This also affects platform branching and needs to be solved
before f30. It should be easy to automate this. And there's
no point in limiting that to platform branching.
> d) A packager decides to retire a library and they check nothing in Fedora
> requires it.
Similar to a) and b). They need to check the currently supported
modules as well.
> I wonder how are such situations meant to be handled with modules?
> Do we build modules for rawhide? If so, should Fedora changes (such as, but
> not limited to, "the Changes") somehow handle all the modules, or is it the
> modular maintainer responsibility to make sure their module works on the
> next Fedora version?
We're aware there are many gaps here. I consider identifying &
resolving them a priority for the Modularity WG at the moment,
so thank you for contributing.
> For the above examples, here are some more specific situations with more
> specific questions:
>
>
> a) I was planning to propose a more strict "No more automagic Python
> bytecompilation" [1] change for Fedora 30 where we would query all packages
> that depend on the old behavior and mass add "%global
> _python_bytecompile_extra 1" to all of them, so we could switch the default
> to be 0. Normally, we would do it in Rawhide only. But how do I handle
> modules? How do I find out what modular packages rely on the old behavior?
Modules typically build the same content in all contexts
(buildroots). If that's a problem for this particular change
of yours, I think the proper way would be adding %{fedora}
conditionals around that macro definition.
> b) A CVE was filled for Django [2]. How does the security team responsible
> for tracking CVEs figure out we have Django 1.6 in modular Fedora? How is a
> bugzilla filled against a modular package anyway?
They should file a report against Fedora Modules rather than
Fedora, although in practice I suspect people will report bugs
as usual. Then it's about the non-modular package maintainer
re-assigning the bug properly, if necessary.
> c) When we recently mass rebuilt Python 3 packages for Python 3.7, should we
> go and seek for modules that use Python 3 (how do I do that?) and rebuild
> the packages in the modules (or even the modules?)?
Python is part of the "platform" module, so you really need
to check all the RPM stream branches used by the currently
supported modules.
You do not rebuild these packages, you rebuild the modules.
If there's no change to the SPEC files, you'll have to instruct
MBS to do a full rebuild (fedpkg module-build --optional
rebuild_strategy=all). We also plan to add more options to
limit these rebuilds to specific platforms so you wouldn't be
rebuilding for all three or more releases if not required.
> d) (this example is not real (yet)) We decide to retire (remove)
> python2-sphinx because upstream Sphinx no longer supports Python 2. We make
> sure that nothing in Fedora requires or buildrequires it, as all Fedora's
> Python packages use python3-sphinx or no Sphinx at all. However there is a
> Django 1.6 module where python-django uses python2-sphinx to build the docs,
> while python2-sphinx is not part of the module itself. How do we find out
> about this and is it our reprehensibility to keep it in rawhide or add it to
> the module?
I wouldn't say it's your responsibility to resolve the issue
but it is your responsibility to file a bug for the module.
> Sorry if those things are obvious, yet I don't know the answers. There might
> be even more examples where traditionally we would only think rawhide, but
> now with modules the problem seems more complex.
Keep them coming.
I hope this helps at least a little bit, even this late.
P
>
>
> [0] http://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz
> [1] https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1609031
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/X3PSHYHY4GZZP72A2HEBI7V2VVYG26I4/
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
