On Wed, 2023-06-14 at 10:19 +0200, Remi Collet wrote: > Hi, > > Le 13/06/2023 à 18:32, Petr Pisar a écrit : > > > I spent some time thinking how to approximate the nice features > > with current > > state of RPM, Koji, and DNF and come up with this approach > > <https://ppisar.fedorapeople.org/postmodular/>. > > First thanks for your work on this > > I also thinking a lot about this, and this is a nightmare > > I must say that I'm terribly sad we have to reinvent the wheel. > > I'm still a big fan of SCL and I still build them for Fedora > to be able to install multiple versions simultaneously > > # LANG=C dnf list php?? > Installed Packages > php74.x86_64 7.4-3.fc37.remi > php80.x86_64 8.0-3.fc37.remi > php81.x86_64 8.1-4.fc37.remi > php82.x86_64 8.2-5.fc37.remi > php83.x86_64 8.3-1.fc37.remi > > Complexity is for packagers and users. > > I'm also a big fan of modules. > It just works well. > > # dnf module list php > Remi's Modular repository - Fedora 37 - x86_64 > Name Stream Profiles Summary > > php remi-7.4 common [d], devel, minimal PHP > php remi-8.0 common [d], devel, minimal PHP > php remi-8.1 [e] common [d], devel, minimal PHP > php remi-8.2 common [d], devel, minimal PHP > > Complexity is only for build system. > > I will probably never understand hostility from the community > against this (bad feeling because of initial broken implementation ?) In my point of view, modularity goal is have a king SCL (softwarecollections.org), but better, in which allows users have updated versions of some software, because is impossible keep same version of all packages for 10 years, which is the lifetime of RHEL 7, for example. These modules are just an exception thats allow users to run one killing application like Gimp or whatever. But the problem was, everyone started building modules of everything , and that is not the goal of modularity (IMO), do not make sense to me have lastest commit of libpng or whatever since these libs are alerady stable and common user don't need updates. This brings (IMO) a big fragmentation of we can test and how to test. Modules should always be stable things that we haven't already in our environment, and an opt- out in exceptions and not an opt-in. In my point of view, the main goal of modules is for long term distributions like RHEL(s) where for example on Centos 8 Stream, we could have ImageImagick 7 as module, and users have ImageMagick updated which is already needed by another software and run it in an "old" distribution (at the moment they can't). > Perhaps Fedora, with its very short life, don't really needs > alternative > versions, while a long life distro obviously needs it. > > Your approach will move complexity back to packagers. > > 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) > > 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) > An extension of the stack will require the specific stream (build and > run) > > What about CI ? > > An application will be build will one stream (default) > but we probably need to test it with all available streams. > > And perhaps have to use (because not compatible with 3) > Requires: (stream-stack-default or stream-stack-2) > > > 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. > > > > Only my initial comments > > Regards, > 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 -- Sérgio M. B. _______________________________________________ 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
