You triggered my interest, so I tried to get some information how many modules there are in Fedora, but 1) mbs.fedoraproject.org spits on me just some JSON instead of some user friendly web UI, 2) pagure cannot show content of modules namespace nor can reliably search for modules, 3) opening the MBS change [1], says that the documentation is at [2] and this immediately redirects me to [3], where is just some marketing stuff without any useful information. Oh, there is "Docs X" link which points to some documentation URL which has fragments such as "subprojects/fesco", it can't be useful at all, right? Frankly, I cannot imagine that somebody would try it even by accident. V. [1] https://fedoraproject.org/wiki/Changes/ModuleBuildService [2] https://fedoraproject.org/wiki/Modularity/Infra [3] https://docs.pagure.org/modularity/ Dne 3.8.2018 v 16:43 Miro Hrončok napsal(a): > 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: > > > 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]. > > 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. > > c) A new version of interpreted language lands in rawhide. All > packages depending on the interpeter need mass rebuild in a side tag. > > d) A packager decides to retire a library and they check nothing in > Fedora requires it. > > 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? > > > 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? > > 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? > > 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?)? > > 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? > > > 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. > > > [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 _______________________________________________ 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/6IV22UODEYNMJ7C34U54OLACCE2FXSHE/
