"virt" modules and discrepancies vs Rocky
Hello,
We've just been bit by some libvirt updates in our project (Apache Cloudstack) which basically broke basic functionality on AlmaLinux 8.4. I expected the same problem to happen on RockyLinux 8.4, however turns out the libvirt on this one was an older version and not even "yum update" changed this. On closer investigation I noticed Rocky actually ships 5 "virt" modules, according to "yum module info virt", my Alma test box only ships one, which is also very up to date.
No actual complaints here, but can someone explain to me why the discrepancy? Didn't use EL8 much, but expected all "clones" to be more or less identical, but turns out there are differences that matter.
Thanks
On Fri, May 13, 2022 at 6:18 AM Nux nux@li.nux.ro wrote:
Hello,
We've just been bit by some libvirt updates in our project (Apache Cloudstack) which basically broke basic functionality on AlmaLinux 8.4. I expected the same problem to happen on RockyLinux 8.4, however turns out the libvirt on this one was an older version and not even "yum update" changed this. On closer investigation I noticed Rocky actually ships 5 "virt" modules, according to "yum module info virt", my Alma test box only ships one, which is also very up to date.
No actual complaints here, but can someone explain to me why the discrepancy? Didn't use EL8 much, but expected all "clones" to be more or less identical, but turns out there are differences that matter.
I don't know what's going on, but RHEL and CentOS Stream 8 only have a virt:rhel stream, so there shouldn't be such weird modules. AlmaLinux only has virt:rhel, just like RHEL itself.
On Fri, 13 May 2022 at 06:18, Nux nux@li.nux.ro wrote:
Hello,
We've just been bit by some libvirt updates in our project (Apache Cloudstack) which basically broke basic functionality on AlmaLinux 8.4. I expected the same problem to happen on RockyLinux 8.4, however turns out the libvirt on this one was an older version and not even "yum update" changed this. On closer investigation I noticed Rocky actually ships 5 "virt" modules, according to "yum module info virt", my Alma test box only ships one, which is also very up to date.
No actual complaints here, but can someone explain to me why the discrepancy? Didn't use EL8 much, but expected all "clones" to be more or less identical, but turns out there are differences that matter.
Hmm I do not know what is going on with the Rocky side of things, but I am guessing there might have been a mismatch on how to build module 'versions' as module 'streams'. Let us look at perl and virt as examples. RHEL offers 4 perl streams with different lifetimes and support leveles ( https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle ) and only one virt stream. ``` [root@vector-8 ~]# dnf module list perl Updating Subscription Management repositories. Last metadata expiration check: 1:11:06 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary
perl 5.24 common [d], minimal Practical Extraction and Report Language perl 5.26 [d][e] common [d], minimal Practical Extraction and Report Language perl 5.30 common [d], minimal Practical Extraction and Report Language perl 5.32 common [d], minimal Practical Extraction and Report Language
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled [root@vector-8 ~]# dnf module list virt Updating Subscription Management repositories. Last metadata expiration check: 1:11:20 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary
virt rhel [d][e] common [d] Virtualization module
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled ```
The virt module has had multiple versions over its lifetime with RHEL-8. The EPEL build system accidently keeps a list of them due to grobisplitter putting them into trees when they are first seen.
``` 2019-09-19 virt:rhel:8000020190618154454:f8e95b4e:x86_64/ 2019-11-07 virt:rhel:8000020190828150510:f8e95b4e:x86_64/ 2019-12-18 virt:rhel:8010020190916153839:cdc1202b:x86_64/ 2020-01-30 virt:rhel:8010020191202185848:c27ad7f8:x86_64/ 2020-04-08 virt:rhel:8010020191216093608:c27ad7f8:x86_64/ 2020-04-29 virt:rhel:8010020200304114113:c27ad7f8:x86_64/ 2020-07-01 virt:rhel:8020020200316135718:6a468ee4:x86_64/ 2020-09-30 virt:rhel:8020020200601195459:4cda2c84:x86_64/ 2020-11-03 virt:rhel:8020020200909224913:4cda2c84:x86_64/ 2020-12-16 virt:rhel:8030020200909014558:30b713e6:x86_64/ 2021-02-17 virt:rhel:8030020201123162111:229f0a1c:x86_64/ 2021-03-04 virt:rhel:8030020210205201602:229f0a1c:x86_64/ 2021-05-21 virt:rhel:8030020210210212009:229f0a1c:x86_64/ 2021-08-11 virt:rhel:8040020210317013608:9f9e2e7e:x86_64/ 2021-11-10 virt:rhel:8040020210721215855:522a0ee4:x86_64/ 2021-12-22 virt:rhel:8050020211001230723:b4937e53:x86_64/ 2022-02-02 virt:rhel:8050020211203195115:c5368500:x86_64/ 2022-03-16 virt:rhel:8050020220113125354:c5368500:x86_64/ 2022-04-27 virt:rhel:8050020220208234339:c5368500:x86_64/ 2022-05-11 virt:rhel:8050020220322234807:c5368500:x86_64/ 2022-05-11 virt:rhel:8060020220408104655:d63f516d:x86_64/ ```
To a user you should see only one module stream which is virt:rhel. It should then continuously get updated when the 'version' of the module is updated and all the packages in this 'pseudo-repository' are updated en-mass. I do not know how Rocky has split things up and it could be for multiple reasons like they are offering alternative streams or their tooling at one point split things in different ways than RHEL does.
Thanks both.
This is what I saw in that particular Rocky installation: https://pastebin.com/raw/bKnFMM9a
But I'll do a fresh comparison between all clones as soon as I get some time and try to get to the bottom of it.
--- Nux www.nux.ro [1]
On 2022-05-13 13:03, Stephen John Smoogen wrote:
On Fri, 13 May 2022 at 06:18, Nux nux@li.nux.ro wrote:
Hello,
We've just been bit by some libvirt updates in our project (Apache Cloudstack) which basically broke basic functionality on AlmaLinux 8.4. I expected the same problem to happen on RockyLinux 8.4, however turns out the libvirt on this one was an older version and not even "yum update" changed this. On closer investigation I noticed Rocky actually ships 5 "virt" modules, according to "yum module info virt", my Alma test box only ships one, which is also very up to date.
No actual complaints here, but can someone explain to me why the discrepancy? Didn't use EL8 much, but expected all "clones" to be more or less identical, but turns out there are differences that matter.
Hmm I do not know what is going on with the Rocky side of things, but I am guessing there might have been a mismatch on how to build module 'versions' as module 'streams'. Let us look at perl and virt as examples. RHEL offers 4 perl streams with different lifetimes and support leveles ( https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle ) and only one virt stream.
[root@vector-8 ~]# dnf module list perl Updating Subscription Management repositories. Last metadata expiration check: 1:11:06 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary perl 5.24 common [d], minimal Practical Extraction and Report Language perl 5.26 [d][e] common [d], minimal Practical Extraction and Report Language perl 5.30 common [d], minimal Practical Extraction and Report Language perl 5.32 common [d], minimal Practical Extraction and Report Language Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled [root@vector-8 ~]# dnf module list virt Updating Subscription Management repositories. Last metadata expiration check: 1:11:20 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary virt rhel [d][e] common [d] Virtualization module Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalledThe virt module has had multiple versions over its lifetime with RHEL-8. The EPEL build system accidently keeps a list of them due to grobisplitter putting them into trees when they are first seen.
2019-09-19 virt:rhel:8000020190618154454:f8e95b4e:x86_64/ 2019-11-07 virt:rhel:8000020190828150510:f8e95b4e:x86_64/ 2019-12-18 virt:rhel:8010020190916153839:cdc1202b:x86_64/ 2020-01-30 virt:rhel:8010020191202185848:c27ad7f8:x86_64/ 2020-04-08 virt:rhel:8010020191216093608:c27ad7f8:x86_64/ 2020-04-29 virt:rhel:8010020200304114113:c27ad7f8:x86_64/ 2020-07-01 virt:rhel:8020020200316135718:6a468ee4:x86_64/ 2020-09-30 virt:rhel:8020020200601195459:4cda2c84:x86_64/ 2020-11-03 virt:rhel:8020020200909224913:4cda2c84:x86_64/ 2020-12-16 virt:rhel:8030020200909014558:30b713e6:x86_64/ 2021-02-17 virt:rhel:8030020201123162111:229f0a1c:x86_64/ 2021-03-04 virt:rhel:8030020210205201602:229f0a1c:x86_64/ 2021-05-21 virt:rhel:8030020210210212009:229f0a1c:x86_64/ 2021-08-11 virt:rhel:8040020210317013608:9f9e2e7e:x86_64/ 2021-11-10 virt:rhel:8040020210721215855:522a0ee4:x86_64/ 2021-12-22 virt:rhel:8050020211001230723:b4937e53:x86_64/ 2022-02-02 virt:rhel:8050020211203195115:c5368500:x86_64/ 2022-03-16 virt:rhel:8050020220113125354:c5368500:x86_64/ 2022-04-27 virt:rhel:8050020220208234339:c5368500:x86_64/ 2022-05-11 virt:rhel:8050020220322234807:c5368500:x86_64/ 2022-05-11 virt:rhel:8060020220408104655:d63f516d:x86_64/To a user you should see only one module stream which is virt:rhel. It should then continuously get updated when the 'version' of the module is updated and all the packages in this 'pseudo-repository' are updated en-mass. I do not know how Rocky has split things up and it could be for multiple reasons like they are offering alternative streams or their tooling at one point split things in different ways than RHEL does. --
Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren _______________________________________________ Devel mailing list -- devel@lists.almalinux.org To unsubscribe send an email to devel-leave@lists.almalinux.org
Links: ------ [1] http://www.nux.ro
On Fri, 13 May 2022 at 08:12, Nux nux@li.nux.ro wrote:
Thanks both.
This is what I saw in that particular Rocky installation: https://pastebin.com/raw/bKnFMM9a
But I'll do a fresh comparison between all clones as soon as I get some time and try to get to the bottom of it.
OK, that is weird. It is showing each past 'version' like it was completely different. I am wondering if there is some sort of dnf config option in play here. It might be possible to set up dnf to not see each version in a stream as different enough so you could 'hard swap' between them versus let them update continuously.. something like RHEL/Alma config: compare stream and update to newer version of any release your system: compare stream:version and only update if forced with a swap.
I would check with Oracle and see how they are doing things also.
Nux www.nux.ro
On 2022-05-13 13:03, Stephen John Smoogen wrote:
On Fri, 13 May 2022 at 06:18, Nux nux@li.nux.ro wrote:
Hello,
We've just been bit by some libvirt updates in our project (Apache Cloudstack) which basically broke basic functionality on AlmaLinux 8.4. I expected the same problem to happen on RockyLinux 8.4, however turns out the libvirt on this one was an older version and not even "yum update" changed this. On closer investigation I noticed Rocky actually ships 5 "virt" modules, according to "yum module info virt", my Alma test box only ships one, which is also very up to date.
No actual complaints here, but can someone explain to me why the discrepancy? Didn't use EL8 much, but expected all "clones" to be more or less identical, but turns out there are differences that matter.
Hmm I do not know what is going on with the Rocky side of things, but I am guessing there might have been a mismatch on how to build module 'versions' as module 'streams'. Let us look at perl and virt as examples. RHEL offers 4 perl streams with different lifetimes and support leveles ( https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle ) and only one virt stream.
[root@vector-8 ~]# dnf module list perl Updating Subscription Management repositories. Last metadata expiration check: 1:11:06 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary perl 5.24 common [d], minimal Practical Extraction and Report Language perl 5.26 [d][e] common [d], minimal Practical Extraction and Report Language perl 5.30 common [d], minimal Practical Extraction and Report Language perl 5.32 common [d], minimal Practical Extraction and Report Language Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled [root@vector-8 ~]# dnf module list virt Updating Subscription Management repositories. Last metadata expiration check: 1:11:20 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary virt rhel [d][e] common [d] Virtualization module Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalledThe virt module has had multiple versions over its lifetime with RHEL-8. The EPEL build system accidently keeps a list of them due to grobisplitter putting them into trees when they are first seen.
2019-09-19 virt:rhel:8000020190618154454:f8e95b4e:x86_64/ 2019-11-07 virt:rhel:8000020190828150510:f8e95b4e:x86_64/ 2019-12-18 virt:rhel:8010020190916153839:cdc1202b:x86_64/ 2020-01-30 virt:rhel:8010020191202185848:c27ad7f8:x86_64/ 2020-04-08 virt:rhel:8010020191216093608:c27ad7f8:x86_64/ 2020-04-29 virt:rhel:8010020200304114113:c27ad7f8:x86_64/ 2020-07-01 virt:rhel:8020020200316135718:6a468ee4:x86_64/ 2020-09-30 virt:rhel:8020020200601195459:4cda2c84:x86_64/ 2020-11-03 virt:rhel:8020020200909224913:4cda2c84:x86_64/ 2020-12-16 virt:rhel:8030020200909014558:30b713e6:x86_64/ 2021-02-17 virt:rhel:8030020201123162111:229f0a1c:x86_64/ 2021-03-04 virt:rhel:8030020210205201602:229f0a1c:x86_64/ 2021-05-21 virt:rhel:8030020210210212009:229f0a1c:x86_64/ 2021-08-11 virt:rhel:8040020210317013608:9f9e2e7e:x86_64/ 2021-11-10 virt:rhel:8040020210721215855:522a0ee4:x86_64/ 2021-12-22 virt:rhel:8050020211001230723:b4937e53:x86_64/ 2022-02-02 virt:rhel:8050020211203195115:c5368500:x86_64/ 2022-03-16 virt:rhel:8050020220113125354:c5368500:x86_64/ 2022-04-27 virt:rhel:8050020220208234339:c5368500:x86_64/ 2022-05-11 virt:rhel:8050020220322234807:c5368500:x86_64/ 2022-05-11 virt:rhel:8060020220408104655:d63f516d:x86_64/To a user you should see only one module stream which is virt:rhel. It should then continuously get updated when the 'version' of the module is updated and all the packages in this 'pseudo-repository' are updated en-mass. I do not know how Rocky has split things up and it could be for multiple reasons like they are offering alternative streams or their tooling at one point split things in different ways than RHEL does.
-- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
Devel mailing list -- devel@lists.almalinux.org To unsubscribe send an email to devel-leave@lists.almalinux.org
Thanks, yes, it does sound weird and will double check for any pebkac issues, too.
Oracle EL is definitely on the list, will check it, as well.
I wish they stuck to software collections, really.
--- Nux www.nux.ro [1]
On 2022-05-13 13:25, Stephen John Smoogen wrote:
On Fri, 13 May 2022 at 08:12, Nux nux@li.nux.ro wrote:
Thanks both.
This is what I saw in that particular Rocky installation: https://pastebin.com/raw/bKnFMM9a
But I'll do a fresh comparison between all clones as soon as I get some time and try to get to the bottom of it.
OK, that is weird. It is showing each past 'version' like it was completely different. I am wondering if there is some sort of dnf config option in play here. It might be possible to set up dnf to not see each version in a stream as different enough so you could 'hard swap' between them versus let them update continuously.. something like RHEL/Alma config: compare stream and update to newer version of any release your system: compare stream:version and only update if forced with a swap.
I would check with Oracle and see how they are doing things also.
Nux www.nux.ro [1]
On 2022-05-13 13:03, Stephen John Smoogen wrote:
On Fri, 13 May 2022 at 06:18, Nux nux@li.nux.ro wrote: Hello,
We've just been bit by some libvirt updates in our project (Apache Cloudstack) which basically broke basic functionality on AlmaLinux 8.4. I expected the same problem to happen on RockyLinux 8.4, however turns out the libvirt on this one was an older version and not even "yum update" changed this. On closer investigation I noticed Rocky actually ships 5 "virt" modules, according to "yum module info virt", my Alma test box only ships one, which is also very up to date.
No actual complaints here, but can someone explain to me why the discrepancy? Didn't use EL8 much, but expected all "clones" to be more or less identical, but turns out there are differences that matter.
Hmm I do not know what is going on with the Rocky side of things, but I am guessing there might have been a mismatch on how to build module 'versions' as module 'streams'. Let us look at perl and virt as examples. RHEL offers 4 perl streams with different lifetimes and support leveles ( https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle ) and only one virt stream.
[root@vector-8 ~]# dnf module list perl Updating Subscription Management repositories. Last metadata expiration check: 1:11:06 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary perl 5.24 common [d], minimal Practical Extraction and Report Language perl 5.26 [d][e] common [d], minimal Practical Extraction and Report Language perl 5.30 common [d], minimal Practical Extraction and Report Language perl 5.32 common [d], minimal Practical Extraction and Report Language Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled [root@vector-8 ~]# dnf module list virt Updating Subscription Management repositories. Last metadata expiration check: 1:11:20 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary virt rhel [d][e] common [d] Virtualization module Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalledThe virt module has had multiple versions over its lifetime with RHEL-8. The EPEL build system accidently keeps a list of them due to grobisplitter putting them into trees when they are first seen.
2019-09-19 virt:rhel:8000020190618154454:f8e95b4e:x86_64/ 2019-11-07 virt:rhel:8000020190828150510:f8e95b4e:x86_64/ 2019-12-18 virt:rhel:8010020190916153839:cdc1202b:x86_64/ 2020-01-30 virt:rhel:8010020191202185848:c27ad7f8:x86_64/ 2020-04-08 virt:rhel:8010020191216093608:c27ad7f8:x86_64/ 2020-04-29 virt:rhel:8010020200304114113:c27ad7f8:x86_64/ 2020-07-01 virt:rhel:8020020200316135718:6a468ee4:x86_64/ 2020-09-30 virt:rhel:8020020200601195459:4cda2c84:x86_64/ 2020-11-03 virt:rhel:8020020200909224913:4cda2c84:x86_64/ 2020-12-16 virt:rhel:8030020200909014558:30b713e6:x86_64/ 2021-02-17 virt:rhel:8030020201123162111:229f0a1c:x86_64/ 2021-03-04 virt:rhel:8030020210205201602:229f0a1c:x86_64/ 2021-05-21 virt:rhel:8030020210210212009:229f0a1c:x86_64/ 2021-08-11 virt:rhel:8040020210317013608:9f9e2e7e:x86_64/ 2021-11-10 virt:rhel:8040020210721215855:522a0ee4:x86_64/ 2021-12-22 virt:rhel:8050020211001230723:b4937e53:x86_64/ 2022-02-02 virt:rhel:8050020211203195115:c5368500:x86_64/ 2022-03-16 virt:rhel:8050020220113125354:c5368500:x86_64/ 2022-04-27 virt:rhel:8050020220208234339:c5368500:x86_64/ 2022-05-11 virt:rhel:8050020220322234807:c5368500:x86_64/ 2022-05-11 virt:rhel:8060020220408104655:d63f516d:x86_64/To a user you should see only one module stream which is virt:rhel. It should then continuously get updated when the 'version' of the module is updated and all the packages in this 'pseudo-repository' are updated en-mass. I do not know how Rocky has split things up and it could be for multiple reasons like they are offering alternative streams or their tooling at one point split things in different ways than RHEL does. --
Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren _______________________________________________ Devel mailing list -- devel@lists.almalinux.org To unsubscribe send an email to devel-leave@lists.almalinux.org
On Fri, 13 May 2022 at 08:29, Nux nux@li.nux.ro wrote:
Thanks, yes, it does sound weird and will double check for any pebkac issues, too.
Oracle EL is definitely on the list, will check it, as well.
I wish they stuck to software collections, really.
Both solutions have had significant 'user' and 'developer' pushback. Many groups (developers, users, customers, IT groups,etc) complained about how bad SCL's were and asked for changes that were then implemented into modularity. I find it sort of like a 'Beware of what you complain about, someone may try to fix it.'
Nux www.nux.ro
On 2022-05-13 13:25, Stephen John Smoogen wrote:
On Fri, 13 May 2022 at 08:12, Nux nux@li.nux.ro wrote:
Thanks both.
This is what I saw in that particular Rocky installation: https://pastebin.com/raw/bKnFMM9a
But I'll do a fresh comparison between all clones as soon as I get some time and try to get to the bottom of it.
OK, that is weird. It is showing each past 'version' like it was completely different. I am wondering if there is some sort of dnf config option in play here. It might be possible to set up dnf to not see each version in a stream as different enough so you could 'hard swap' between them versus let them update continuously.. something like RHEL/Alma config: compare stream and update to newer version of any release your system: compare stream:version and only update if forced with a swap.
I would check with Oracle and see how they are doing things also.
Nux www.nux.ro
On 2022-05-13 13:03, Stephen John Smoogen wrote:
On Fri, 13 May 2022 at 06:18, Nux nux@li.nux.ro wrote:
Hello,
We've just been bit by some libvirt updates in our project (Apache Cloudstack) which basically broke basic functionality on AlmaLinux 8.4. I expected the same problem to happen on RockyLinux 8.4, however turns out the libvirt on this one was an older version and not even "yum update" changed this. On closer investigation I noticed Rocky actually ships 5 "virt" modules, according to "yum module info virt", my Alma test box only ships one, which is also very up to date.
No actual complaints here, but can someone explain to me why the discrepancy? Didn't use EL8 much, but expected all "clones" to be more or less identical, but turns out there are differences that matter.
Hmm I do not know what is going on with the Rocky side of things, but I am guessing there might have been a mismatch on how to build module 'versions' as module 'streams'. Let us look at perl and virt as examples. RHEL offers 4 perl streams with different lifetimes and support leveles ( https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle ) and only one virt stream.
[root@vector-8 ~]# dnf module list perl Updating Subscription Management repositories. Last metadata expiration check: 1:11:06 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary perl 5.24 common [d], minimal Practical Extraction and Report Language perl 5.26 [d][e] common [d], minimal Practical Extraction and Report Language perl 5.30 common [d], minimal Practical Extraction and Report Language perl 5.32 common [d], minimal Practical Extraction and Report Language Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled [root@vector-8 ~]# dnf module list virt Updating Subscription Management repositories. Last metadata expiration check: 1:11:20 ago on Fri 13 May 2022 06:44:03 EDT. Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) Name Stream Profiles Summary virt rhel [d][e] common [d] Virtualization module Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalledThe virt module has had multiple versions over its lifetime with RHEL-8. The EPEL build system accidently keeps a list of them due to grobisplitter putting them into trees when they are first seen.
2019-09-19 virt:rhel:8000020190618154454:f8e95b4e:x86_64/ 2019-11-07 virt:rhel:8000020190828150510:f8e95b4e:x86_64/ 2019-12-18 virt:rhel:8010020190916153839:cdc1202b:x86_64/ 2020-01-30 virt:rhel:8010020191202185848:c27ad7f8:x86_64/ 2020-04-08 virt:rhel:8010020191216093608:c27ad7f8:x86_64/ 2020-04-29 virt:rhel:8010020200304114113:c27ad7f8:x86_64/ 2020-07-01 virt:rhel:8020020200316135718:6a468ee4:x86_64/ 2020-09-30 virt:rhel:8020020200601195459:4cda2c84:x86_64/ 2020-11-03 virt:rhel:8020020200909224913:4cda2c84:x86_64/ 2020-12-16 virt:rhel:8030020200909014558:30b713e6:x86_64/ 2021-02-17 virt:rhel:8030020201123162111:229f0a1c:x86_64/ 2021-03-04 virt:rhel:8030020210205201602:229f0a1c:x86_64/ 2021-05-21 virt:rhel:8030020210210212009:229f0a1c:x86_64/ 2021-08-11 virt:rhel:8040020210317013608:9f9e2e7e:x86_64/ 2021-11-10 virt:rhel:8040020210721215855:522a0ee4:x86_64/ 2021-12-22 virt:rhel:8050020211001230723:b4937e53:x86_64/ 2022-02-02 virt:rhel:8050020211203195115:c5368500:x86_64/ 2022-03-16 virt:rhel:8050020220113125354:c5368500:x86_64/ 2022-04-27 virt:rhel:8050020220208234339:c5368500:x86_64/ 2022-05-11 virt:rhel:8050020220322234807:c5368500:x86_64/ 2022-05-11 virt:rhel:8060020220408104655:d63f516d:x86_64/To a user you should see only one module stream which is virt:rhel. It should then continuously get updated when the 'version' of the module is updated and all the packages in this 'pseudo-repository' are updated en-mass. I do not know how Rocky has split things up and it could be for multiple reasons like they are offering alternative streams or their tooling at one point split things in different ways than RHEL does.
-- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
Devel mailing list -- devel@lists.almalinux.org To unsubscribe send an email to devel-leave@lists.almalinux.org
-- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
On Fri, May 13, 2022 at 8:48 AM Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 13 May 2022 at 08:29, Nux nux@li.nux.ro wrote:
Thanks, yes, it does sound weird and will double check for any pebkac issues, too.
Oracle EL is definitely on the list, will check it, as well.
I wish they stuck to software collections, really.
Both solutions have had significant 'user' and 'developer' pushback. Many groups (developers, users, customers, IT groups,etc) complained about how bad SCL's were and asked for changes that were then implemented into modularity. I find it sort of like a 'Beware of what you complain about, someone may try to fix it.'
With an EL9 lens (as that's where most of my focus is these days), the only real complaint I have about modules these days is that the official module build infrastructure requires too much information and access to build modules on top of modules. For work, we use an Open Build Service instance for our build system and it supports enabling modules per project/package build without having to require interacting with the target distribution's Koji instance (as MBS does).
If there was something I'd wave a wand about, it'd be that EPEL would be able to build on top of RHEL modules properly[1] and not require people to figure out build orders by default[2].
[1]: https://pagure.io/fm-orchestrator/issue/1653 [2]: https://pagure.io/fm-orchestrator/issue/1241
Jesus.. sounds like gone are the days when a man could just "mock" a repo around.
--- Nux www.nux.ro
On 2022-05-13 14:26, Neal Gompa wrote:
On Fri, May 13, 2022 at 8:48 AM Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 13 May 2022 at 08:29, Nux nux@li.nux.ro wrote:
Thanks, yes, it does sound weird and will double check for any pebkac issues, too.
Oracle EL is definitely on the list, will check it, as well.
I wish they stuck to software collections, really.
Both solutions have had significant 'user' and 'developer' pushback. Many groups (developers, users, customers, IT groups,etc) complained about how bad SCL's were and asked for changes that were then implemented into modularity. I find it sort of like a 'Beware of what you complain about, someone may try to fix it.'
With an EL9 lens (as that's where most of my focus is these days), the only real complaint I have about modules these days is that the official module build infrastructure requires too much information and access to build modules on top of modules. For work, we use an Open Build Service instance for our build system and it supports enabling modules per project/package build without having to require interacting with the target distribution's Koji instance (as MBS does).
If there was something I'd wave a wand about, it'd be that EPEL would be able to build on top of RHEL modules properly[1] and not require people to figure out build orders by default[2].
On Fri, May 13, 2022 at 9:37 AM Nux nux@li.nux.ro wrote:
Jesus.. sounds like gone are the days when a man could just "mock" a repo around.
Ironically, that does mostly work. Both Mock and Koji themselves can do this reasonably well, it's just the MBS addon that's horribly broken.
participants (3)
-
Neal Gompa -
Nux -
Stephen John Smoogen