V Wed, Jun 14, 2023 at 10:19:27AM +0200, Remi Collet napsal(a): > Your approach will move complexity back to packagers. > Yes. That's because the problem has a complexity and the complexity needs to live somewhere. With modularity it was in MBS and in modular filtering part of DNF. If you remove modularity, the complexity has to emerge again somewhere. With my approach the somwehere is new metapackages, new dependencies, and new build targets.
> I'm also very concerned by the "vendor" approach > > It seems possible using some stream-<module>-<vendor>-<stream> > (or <stream> being vendor-number, as with module) > I don't understand it. Do you mean that anybody can add his own stream, or sqaut a namespace? Yes, he can. It was possible even in modularity. Here it is worse because those identifiers are free-style package names. There are no separate fields or entities designated for <module> and <stream> anymore. > It seems also need to manage dependency with a stack or with a specific > stream. > > Ex: > An application will require the default stack (build and run) If the application ignores nondefault stacks, no action is required. That's why the proposal is so obsesed with default streams. I think this will be the most prevaling case. E.g. automake is written in Perl and an automake maintainer does not care whether it works with alternative Perls or not. He does not have to. The same attitude was used in modularity. > An extension of the stack will require the specific stream (build and run) > The extension can add build- and run-time dependenices on packages from that stream. However, that will effectively make the extension part of the stream. In that case a maintainer of the extension should including it into the stream. That, by a the proposed recommendations, would change an RPM name of the extension. I guess that Fedora would insist on this name change as Fedora's packaging guidelines now insist on nonmodular packages to only depend on nonmodular content. On the other hand, I can imagine that packages (especially top-level applications) which are not a logical part of any specific stream but depends on that nondefault stream, will retain its original name and simply users will have to switch the stream with "--allowerasing". It's the fragmentation of well-integrated Fedora Christopher (?) wrote in this thread. In his eyes there is no need for applications like that. > What about CI ? > CI would have to adapt to switch the streams. As in case of modularity. As far as I know Fedora does not supports modules in CI. But the switching can happen as an implicit part of CI environment installation. If CI populated the enviromemnt with "dnf --root=... install <THE_TESTED_PACKAGE> <PACKAGES_USED_BY_CI>, then DNF would pick the fitting streams automatically. Or if there were no solution, DNF would report a dependency resolution error. > An application will be build will one stream (default) > but we probably need to test it with all available streams. > That would be difficult to automate. Packagers could configure CI to repeat tests for listed streams. Modularity was better for automation because streams were a formal entity which could be queried and set. In the my approach there is no such capability because simply there is no modular entity. That's definitely a regression. Howver, in reality the automation even in RHEL was not so hot. As far as I know a list of stream combinations to test was always defined statically. > And perhaps have to use (because not compatible with 3) > Requires: (stream-stack-default or stream-stack-2) > Rich dependencices are one option. Another option is to leverage ordering. Because the packages from streams provide the same base name with different versions: php74 Provides: php = 7.4 php80 Provides: php = 8.0 php82 Provides: php = 8.2 then you can write "Requires: php >= 8.0" to exclude php-7.4. Now I'm not sure whether versioning stream-stack from your question wouldn't break default streams. I forgot whether DNF prefers a package with highest provider or a package with highest version and whether the versioning is stronger than weak dependencies or not. > What about reviews ? > > If I want to create stream-stack-3, with 100 packages ? > > For now, there is a review exception for compatibility packages > for "older" version, but not for newer version. > Good catch. Fedora would have to change rules to recognize that stack3 is an upgrade of stack2. Or those could live in stream branches of dist-git where they hide in repository under the base name. Frankly I haven't yet thought on these policies Fedora asserts. So far I thinking on feasibily from DNF and Koji point of view. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
