----- Original Message ----- > From: "Matthew Miller" <mattdm@xxxxxxxxxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Monday, October 7, 2019 4:31:18 PM > Subject: Re: Modularity and the system-upgrade path > > On Mon, Oct 07, 2019 at 03:20:21PM -0400, Alexander Scheel wrote: > > > And where is the software for those containers coming from? Some > > > container registry like Docker Hub? One of the main points of > > > Modularity is to provide a trusted source of software to install into > > > containers. > > I never really understood this argument. Could you help me understand > > it? > > In what way do ursine RPMs not already do this? And more importantly, > > what benefits does Modularity bring, based on an earlier thread with > > Modularity use cases? > > I'm going to avoid the word "ursine" because I think it's more confusing > then helpful. It's all the same RPMs, after all. Ok... But we need some word to describe "RPMs without weird context that behave like they're supposed to and somebody maintains them" instead of "RPMs in a module somewhere". Otherwise the discussion gets confusing fast. So if you don't mind, I'll stick with "ursine RPMs" vs "modular RPMs" for now. :) > Without modularity, RPM doesn't offer a good way to choose between different > versions of the same thing. One can squash version numbers into the name, > which covers some use cases, but also becomes unwieldy and loses the _idea_ > that these things are different branches of the same basic software. This is not true at all. For starters, if you have parallel packages available [0], `rpm -i` will let you install them all just fine and track each individually [1]. When you go to uninstall it (`rpm -e rpm-test`), it'll complain that you didn't specify which one [2], so you'll of course have to specify a version [3]. If you then go stick it in a repo, DNF will show you the highest version, which is expected since DNF generally concerns itself with the updated-ness of your system [4]. But you can always pass --showduplicates to show the older versions. And nothing prevents you from selecting a different version of the package if they exist in the repo [5]. The one place this fails is that DNF will perform an upgrade, removing the older version, even if you choose install [6]. So really, the only thing missing here is an option to make `dnf install` mean "install" and not "install or upgrade, whatever DNF feels is best". And then you can do all your user intent on the side: I installed "rpm-test-1.0", so I should always keep it installed... but if I also install "rpm-test", I should take whatever version that was and upgrade it... etc. To be fair, the packages in [0] are parallel installable too. But for the case where you only want parallel availability, you already have that, and can use dnf version locking [7] to prevent unintended upgrades if you manually specified a version. So I really think this is a non-issue in ursine RPMs. Modularity only gives you a way to group packages together, like software collections would've. It seems like the problem isn't in RPM or DNF, but is instead in Fedora's package tooling not letting you ship multiple versions of ursine RPMs without modularity. :) But while it might work better, it wouldn't be as cool and sexy as modules... > > > - Modularity doesn't bring parallel-installability. You'd have to support > > it at the RPM level, which means ursine RPMs would support it to. [0] > > Well, the idea is: if you need parallel install, don't mess with it at the > RPM level. Separate at the container level. See above; RPM actually supports parallel install just fine. We just need packaging guidelines we all agree on to ensure packages at different versions don't conflict and what that means. And lots of upstream work to make that happen for the packages we care about. And a little bit of alternatives magic to choose a default version for us and let us switch conveniently. > > > > - Any size reduction in modular RPMs can be made to urisine RPMs. > > Maybe. But what if it reduces functionality? Modularity allows there to be a > reduced version or a full version which can be swapped in. > > > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > 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 > [0]: https://github.com/cipherboy/testbed/rpm-versions [1]: # rpm -qa | grep -i 'rpm-test' | sort rpm-test-1.0-1.x86_64 rpm-test-1.1-1.x86_64 rpm-test-2.0-1.x86_64 [2]: # rpm -e rpm-test error: "rpm-test" specifies multiple packages: rpm-test-1.0-1.x86_64 rpm-test-1.1-1.x86_64 rpm-test-2.0-1.x86_64 [3]: # rpm -e rpm-test-1.0 # rpm -e rpm-test-1.1 # rpm -e rpm-test-2.0 [4]: # dnf info rpm-test Available Packages Name : rpm-test Version : 2.0 Release : 1 Architecture : x86_64 Size : 6.8 k Source : rpm-test-2.0-1.src.rpm Repository : Test Summary : A test package for seeing how RPM handles different RPM versions. URL : https://github.com/cipherboy/testbed/rpm-versions License : AGPLv3 Description : A test package for seeing how RPM handles different RPM versions. : : This is version 2.0 [5]: # dnf install rpm-test-1.0 Last metadata expiration check: 0:01:01 ago on Mon 07 Oct 2019 07:36:10 PM EDT. Dependencies resolved. ====================================================================================================================== Package Architecture Version Repository Size ====================================================================================================================== Installing: rpm-test x86_64 1.0-1 Test 6.7 k Transaction Summary ====================================================================================================================== Install 1 Package Total size: 6.7 k Installed size: 12 Is this ok [y/N]: y Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : rpm-test-1.0-1.x86_64 1/1 Verifying : rpm-test-1.0-1.x86_64 1/1 Installed: rpm-test-1.0-1.x86_64 Complete! [6]: # dnf install rpm-test-1.1 Last metadata expiration check: 0:02:21 ago on Mon 07 Oct 2019 07:36:10 PM EDT. Dependencies resolved. ====================================================================================================================== Package Architecture Version Repository Size ====================================================================================================================== Upgrading: rpm-test x86_64 1.1-1 Test 6.8 k Transaction Summary ====================================================================================================================== Upgrade 1 Package Total size: 6.8 k Is this ok [y/N]: y Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Upgrading : rpm-test-1.1-1.x86_64 1/2 Cleanup : rpm-test-1.0-1.x86_64 2/2 Verifying : rpm-test-1.1-1.x86_64 1/2 Verifying : rpm-test-1.0-1.x86_64 2/2 Upgraded: rpm-test-1.1-1.x86_64 Complete! [7]: https://dnf-plugins-core.readthedocs.io/en/latest/versionlock.html _______________________________________________ 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
