Bug 1712810
| Summary: | src packages are listed in virt rhel module for RHEL8.0.0.1 and there are some problems about version checking with virt rhel module. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Lin Liu <linl> | ||||
| Component: | virt-rhel-module | Assignee: | Danilo de Paula <ddepaula> | ||||
| Status: | CLOSED ERRATA | QA Contact: | yalzhang <yalzhang> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 8.0 | CC: | chayang, ddepaula, dyuan, jen, jwboyer, leiwang, lsedlar, psabata, wchadwic, wshi, xiliang, xuzhang, yalzhang, yoguo | ||||
| Target Milestone: | rc | Keywords: | Regression | ||||
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | virt-rhel-8010020190628173616.cdc1202b | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-11-05 20:49:21 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Lin Liu
2019-05-22 09:50:11 UTC
Created attachment 1571943 [details]
virt:rhel module installation log
Add virt:rhel module installation log.
Add more information: In my guess the reason that liguestfs, supermin, seabios-bin and other packages are not installed with RHEL8.0.0.1 packages are there packages' version are not changed from RHEL8.0.0 to RHEL8.0.0.1, just change the name from el8 to el8.0.0 with the following strings. e.g., libguestfs version in RHEL8.0.0: libguestfs-1:1.38.4-10.module+el8+2709+40ed2f2c.x86_64, in RHEL8.0.0.1: libguestfs-1:1.38.4-10.module+el8.0.0+3075+09be6b65.x86_64. Does this mean virt:rhel doesn't have the version check/control function? It seems like it depends on the yum itself to check which is the latest version. This brings another question, if there is no version control for virt:rhel, the same issue will happen with RHEL8.0.1 and RHEL8.1.0.Z if keep the same way to name the packages. Now the packages version of RHEL8.1.0 are like this: *+el8.1.0*, e.g., libguestfs-1.40.2-4.module+el8.1.0+3225+a8268fde, what's the version look like for RHEL8.1.0.Z packages? Modularity team broke the update path for modular packages when they introduced the 'el8.0.0' thing for every package. Here the thing: Assume this two packages: A: libguestfs-1.40.2-4.module+el8.1.0+3225+a8268fde B: libguestfs-1.40.2-4.module+el8+3000+a8268fde A: was released for RHEL-8.1.0 B: was released for RHEL-8.0.0 This shouldn't cause real harm because even tough B is released later, they have exactly the same content. Essentially they are the same package. Version-Release of both packages are exactly the same. I think they are aware about this. When we mentioned that months ago the proposal was to bump the RELEASE number for every package. Btw, we had to do this bumping for zstream packages updates. But only for the packages we did update. > Here the thing: > > Assume this two packages: > > A: libguestfs-1.40.2-4.module+el8.1.0+3225+a8268fde > B: libguestfs-1.40.2-4.module+el8+3000+a8268fde > > A: was released for RHEL-8.1.0 > B: was released for RHEL-8.0.0 > > This shouldn't cause real harm because even tough B is released later, they Sorry, released earlier. > have exactly the same content. Essentially they are the same package. > Version-Release of both packages are exactly the same. > > I think they are aware about this. When we mentioned that months ago the > proposal was to bump the RELEASE number for every package. > > Btw, we had to do this bumping for zstream packages updates. But only for > the packages we did update. $ rpmdev-vercmp libguestfs-1.40.2-4.module+el8.1.0+3225+a8268fde libguestfs-1.40.2-4.module+el8+3000+a8268fde libguestfs-1.40.2-4.module+el8.1.0+3225+a8268fde < libguestfs-1.40.2-4.module+el8+3000+a8268fde Can someone clarify what the exception? request is for? Is this to simply bump the Release for all packages and ensure the upgrade path succeeds? I don't think the additional stream thing is still an issue, IIRC. The src package listing in the metadata is also not an issue, thought it is confusing. I made a proposal in bug 1723396, which is related to this but with serious consequences Copying from that comment: From my perspective, to be sure this is fixed once for all and we don't brake anything. so we need five BZs: 1 - Bump all virt:rhel packages in rhel-8.0.0-z that are still using single 'el8' scheme (hint: all of them) and release a new zstream upate (with the release field +1). 2 - If we do that, then we also need to bump them in virt:rhel for RHEL-8.1.0 (to be sure they will be higher or, at least equal, in 8.0.0) Same thing for RHEL-AV, but we need three BZs there: 3 - Bump all virt:8.0.0 package versions for RHEL-AV-8.0.0 (looks like every package uses el8 scheme) 4 - Bump all virt:8.0 packages RHEL-AV-8.0.1 5 - Bump all virt:8.1 packages for RHEL-AV-8.1.0 Does it make sense? Is it too harsh? Yes, it makes sense. Related to Bug 1723396 Check on lastest rhel-av-8.1.0 module: module-virt-8.1-8010020190701201736-cdc1202b, all packages has the "el8.1.0" in the suffix.
# yum module info virt:8.1
......
Name : virt
Stream : 8.1 [e] [a]
Version : 8010020190701201736
Context : cdc1202b
Architecture : x86_64
Profiles : common [d] [i]
Default profiles : common
Repo : ci_fast
Summary : Virtualization module
Description : A virtualization module
Artifacts : SLOF-0:20190114-2.gita5b428e.module+el8.1.0+3554+1a3a94a6.noarch
: hivex-0:1.3.15-7.module+el8.1.0+3554+1a3a94a6.x86_64
: hivex-debugsource-0:1.3.15-7.module+el8.1.0+3554+1a3a94a6.x86_64
: hivex-devel-0:1.3.15-7.module+el8.1.0+3554+1a3a94a6.x86_64
......
# yum module info virt:8.1 | grep Artifacts -A200 | grep -v +el8.1.0+
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled, [a]ctive
===> no package without "+el8.1.0+"
BTW, check virt module for other streams:
RHEL-AV-8.0.1 with virt-8.0-8000120190621113320.38bbfdf6: all package have el8.0.1 in the suffix
# yum module info virt:8.0
...
Name : virt
Stream : 8.0 [e] [a]
Version : 8000120190621113320
Context : 38bbfdf6
Profiles : common [d] [i]
Default profiles : common
Repo : ci
Summary : Virtualization module
Description : A virtualization module
Artifacts : SLOF-0:20180702-3.git9b7ab2f.module+el8.0.1+2959+fecd1a40.noarch
: hivex-0:1.3.15-6.module+el8.0.1+2959+fecd1a40.x86_64
: hivex-debugsource-0:1.3.15-6.module+el8.0.1+2959+fecd1a40.x86_64
...
# yum module info virt:8.0 | grep Artifacts -A300 | grep -v +el8.0.1+
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled, [a]ctive]
===> no package without "+el8.0.1+"
Hi Danilo, Please help to check if above check for rhel-av-8.1.0 and rhel-av-8.0.1 virt module in comment 21 is enough for this bug? And I have another 2 questions: 1. Just to confirm, current rhel-8.1.0 virt module still have *.src packages in the module info list, as it is said in comment 14, this is acceptable, right? 2. I found the latest 8.0.0 z stream(both slow and fast train) release have the suffix of "+el8.0.0.z+", what is the background? Is there any bug&doc about this? Thank you very much! For question 0, yes. For question 1: Yes For question 2: This is something that was changed in RHEL build system and we were not notified about it (or maybe I missed the memo). Anyway, it looks bad so I've opened https://projects.engineering.redhat.com/browse/FACTORY-4869 Set the bug to be verified according to above comments. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:3345 |