Le 14/06/2023 à 14:14, Petr Pisar a écrit :
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.
For memory, all RPMs (even modular ones) are build with rpmbuild ;)
mbs is only the "common" way, but not the "simple" way to build modular
packages ;)
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.
Yes, make sense
I was thinking of all C extensions (php-pecl-* and some other)
which have a dependency on php(zend-abi) which is related to
version, and possibly build options (nts, zts, debug...)
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.
Yes, for now we use dependency on php(language)
Usually we only require for minimal version (ex: php(language) >= 8.0)
but sometime range dependency make sense
(ex: roundcubemail which explicitly have a test for maximal version)
BTW, my preferred solution: keep building real modular packages ;)
don't reinvent the wheel.
In all cases, Fedora community won't like it.
Remi
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
