search

doccaz / scc-tools

A set of simple tools to interact with SUSE Customer Center (SCC)
MIT License
13 stars 1 forks source link

possible issue in vercheck.py #13

Closed pzirnik closed 3 years ago

pzirnik commented 3 years ago

I found following difference in the resulted logs

Analyzing supportconfig directory: scc_ABC-SGS-SP808_xxxxxx product name = SUSE Linux Enterprise Server 15 SP1 x86_64 (id 1763, x86_64) found 1171 total packages to check gathering results...

Done. writing CSV reports to scc_ABC-SGS-SP808_xxxxxx

notfound: gnome-desktop,2.28.2-0.6.18 different: gnome-desktop-lang,2.28.2-0.6.18,3.26.2-2.13

as package "gnome-desktop-lang" will be build as sub package of "gnome-desktop" i am pretty sure there is somewhere a error (probably parsing or program logic) hidden in vercheck.py

the affected packages according to rpm.txt

gnome-desktop SUSE Linux Enterprise 11 2.28.2-0.6.18 gnome-desktop-lang SUSE Linux Enterprise 11 2.28.2-0.6.18

probably they are leftovers from a upgrade from SLES11 to SLES15

doccaz commented 3 years ago

You're right. I'm not checking whether the vendor matches the current system version. Maybe I should add a new "unsupported" report where I would place anything that doesn't match the current OS vendor, and remove it from the other reports before writing them. That would also cause the "notfound" report to be considerably smaller, as it usually also contains third-party packages.

What do you think?

frispete commented 3 years ago

From an high level perspective, separating supported (from contract) packages from the rest would be a big win, but I can imagine, that this is hard to achieve.

But the mentioned case is fishy: both packages derive from the same source, but end in different groups.

frispete commented 3 years ago

.. while anything resulting in an uncluttering notfound is welcomed.

Only packages from unknown sources should end in notfound.

doccaz commented 3 years ago

Could you upload that supportconfig (or point it to me at concord/ziu), @pzirnik ?

pzirnik commented 3 years ago

Information has been provided via internal email.

doccaz commented 3 years ago

I think I got an acceptable solution to this problem.

If we're dealing with a known enterprise distribution (sles/sled/sles_sap), the "Vendor" in the packages is usually "SUSE Linux Enterprise [version]" or "SUSE Linux Enterprise [version] [service pack]". The same machine can have packages listed as "SUSE Linux Enterprise 15", "SUSE Linux Enterprise 15 SP3", and so on. This is based on two dozen or so test samples of supportconfig archives. I can cross this with the CPE identifier, extract the system version, and compose a valid partial string (like "SUSE Linux Enterprise 15") to compare the Vendor field to. Whenever the package vendor does not match that partial string and is not found in the regular repositories for the product, it's appended to the "unsupported packages" list. If the package vendor matches the partial string and is not found in the regular repositories for the product, it's appended to the "unknown packages" list.

Thus, in the supplied samples where there are leftover packages from a SLES 11 -> SLES 15 migration, these packages from SLES 11 will be placed in the "unsupported" list, along with other packages that have a vendor of "(none)" and others.

The "notfound" list will contain, for example, packages that have the correct vendor, but belong to a different product (like packages from PackageHub or SUSE Manager).

So far I've ran this modified version against all my samples, and it appears to be working fine.

pzirnik commented 3 years ago

Great !!! :-)