On Tue, Nov 03, 2020 at 02:17:59PM +0100, Petr Šabata wrote: > On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar <ppi...@redhat.com> wrote: > > Another option would be adding the EOL data into modules dist-git > > repositories. To the same branches where modules are built from. But > > a different file. Pungi would enumarate all module builds directed to > > a compose, locate their dist-git sources by mapping name:stream to > > git://src.fedoraproject/org/modules/name.git#stream and download EOL data > > from > > there. That would enable module maintains to control EOLs simply by pushing > > an > > eol.yaml file into the branch of the module. > > This is not a reliable method as the branch name can be anything if > stream name is defined in modulemd. Technically even the repository name > can be anything. > I know. But In my option it's a problem of the module maintainer. (Doctor, it hurts when I stab a needle into my eye! Doctor: Then don't do it.)
And even we had such a module build, the EOL format can be abused the same way. You can EOL/obsolete foreign module:stream. Technically it can be misued the same way to EOL a module build with overriden module:stream. You only need to find a victim module repository to put it into. At the end, we already have a fedora-osbolete-packages package. We can have fedora-obsolete-modules module for the purpose of EOLing misnamed module builds. In my opinion it's only a matter of policy. -- Petr
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
