`package_updates_from_xcdchk` returning incorrect versions for packages

[SchoolGuy]

Describe the bug

At the moment this tool is relying on a best-effort algorithm to match the source and binary packages. This is wrong sometimes in important cases like the kernel.

To Reproduce

Steps to reproduce the behavior:

1. sle-prjmgr-tools package_updates_from_xcdchk -b 64.1 66.1
2. See error

Expected behavior

Since this is also partly a feature request, I will describe the desired behaviour:

• The packages should be grouped by source package.
• Each source package should have the binaries that are updated with the version change listed underneath them.

Logs

Not needed.

Version

#10 not implemented yet

Additional context

Internal RCA is available in the SLE 15 SP5 Confluence space.

[SchoolGuy]

Here is a possible implementation approach.

Corresponding source file: https://github.com/openSUSE/sle-prjmgr-tools/blob/518158724deb439c536953d9e8d5e1eb5195753c/sle_prjmgr_tools/package_updates_from_xcdchk.py

Here a rough first sketch:

class BinaryPackage:
    def __init__(self):
        self.name = ""
        self.filename = ""
        self.repository = ""
        self.arch = ""

class SourcePackage:
    def __init__(self, name: str):
        self.name = name
        self.binaries: List[BinaryPackage] = []

def map_binary_to_source(tbd_parameters**) -> List[SourcePackage]:
    result: List[SourcePackage] = []
    # First loop over the source packages from the changelog that we know
   for package in changelog_packages:
       # Use OscUtils.osc_get_binary_names to get the list of binaries that are valid for the current build
   for rest_package in rest_packages:
       # Now comes the unknown part
       # We have a list of remaining binaries that are not listed in the changelog but are updated due to a rebuild in the dependency chain.
       # The only way we could map these logically easy is, if we retrieve a list of ALL source packages and ALL corresponding binaries from a given project and create a reverse mapping from binary to source package. Maybe if we create a correct XPath this can be done with do_search from osc, however there is no core.py interface atm.

[Werkov]

FTR, not sure if this tools is used for the purpose but we've noticed that kernel version in milestone announcements won't be correctly reported.
Ideally, it should track the version of kernel-default (as shipped in SLES).
However, the output seems to randomly(?) pick -AZURE or -RT kernels that have independent (but visually similar) versioning. As a result, kernel version reported is inconsistent.

[SchoolGuy]

@Werkov it is used for this purpose and yes this bug describes the problem you are seeing. The reasoning is outlined in the bug description.