Hi Igor
On Fri, Nov 15, 2019, 10:03 Nicolas Mailhot via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Le 2019-11-14 22:01, Stephen Gallagher a écrit :
wrote:
On 14. 11. 19 21:32, Stephen Gallagher wrote:
I proposed earlier around the major
upgrade rebuilds (letting us set other modules as
`buildrequires:` of
`python: [ ]` for stream expansion) without actually having to
build
the complete python stack in the modules. That might be a
really
convenient strategy, honestly.
How is that different, exactly, from letting packagers use a normal
dep syntax like
(foo with module(modulename))
whenever they want to express they want the module version of a
particular dep?
Le 2019-11-15 10:11, Igor Gnatenko a écrit :
Except that modular packages shadow non-modular so instead of getting
proper package you will have broken dependency.
What I tried to express is that I do not understand what all those
special module constructs (shadowing, module objects, private packages,
etc) buy us over just expressing module appartenance in normal rpm
module provides
It seems to me, naively, that all the problems modularity is
encountering are generated by those special constructs and those special
module-only management rules, and that the past years have been spent
giving up progressively on unmanageable module-object-specific
behaviors.
Once we’ve gone all the way, and forbade all the special overriding
characteristics that modularity shown did not work, what will be left
over just a very weird and awkward way to express Provides?
If the only sane way we find to achieve modularity, is to use something
very close to module provides, can’t we just drop the special thinguies
and just do it that way? And declare the module-only things a successful
experiment, that helped define the problem space, just not the boring
and reliable way we end up doing it long term?
Regards,
--
Nicolas Mailhot
_______________________________________________
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
