[Devel] Re: "virt" modules and discrepancies vs Rocky

13 May 2022

      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  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  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.
--
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

Links:
------
[1] http://www.nux.ro