Allow additional module registration during package resolution

[atanasdinov]

Currently we only register the default SLE Micro product during package resolution when SCC code is specified. This is not enough to fetch RPMs under additional product modules e.g. SL-Micro-Extras/6.0/x86_64.

To achieve this, specifying the following parameter of SUSEConnect should be set:

    -p, --product [PRODUCT]  Specify a product for activation/deactivation. Only
                             one product can be processed at a time. Defaults to
                             the base SUSE Linux Enterprise product on this
                             system. Product identifiers can be obtained
                             with `--list-extensions`.
                             Format: <name>/<version>/<architecture>

[e-minguez]

As a workaround in the meantime:

• Spin up a fresh SUSE Linux Micro with the same version needed
• Register it
• Activate the module/product required, for Extra for example:

transactional-update register -p SL-Micro-Extras/6.0/aarch64

• Reboot
• Run a temporary and unsupported shell to download the required packages:

transactional-update shell -d
...
zypper in --download-only traceroute
exit

The packages should be in the /var/cache/zypp/ folder:

find /var/cache/zypp/ -iname "*traceroute*"
/var/cache/zypp/packages/SUSE_Linux_Micro_6.0_aarch64:SL-Micro-6.0-Pool/aarch64/traceroute-2.1.3-1.3.aarch64.rpm

Then add those packages to the EIB definition file.

(perhaps the register can be done on the temporary shell as well, didn't tested it)

[jdob]

We discussed this in voice, but to capture the outcome:

The fact that the repo URL contains the version number causes a headache. If it was as simple as saying "SL-Micro-Extras", or even with the arch, we could easily add this into the template.

The problem comes with the fact that the SL Micro version is in the string. We don't have any way inside of EIB to either detect or have the user specify the version of Micro.

The initial plan for 1.2 (with a backport to 1.1) was going to be to hardcode the 6.0 string in the RPM resolution and then revisit in the future when we had more time to think of a clean solution. Now it sounds like 6.1 is a requirement for EIB 1.2, which means we need to figure out a more robust solution than we had hoped.

[jdob]

A possible option instead of adding the version to the definition is to auto-detect it. I worry about the reliability of it, but for the interm (6.0, 6.1, plus the near future), we can probably use /etc/os-release:

6.0

cat /etc/os-release | grep VERSION
VERSION="6.0"
VERSION_ID="6.0"

6.1 Beta 2

cat /etc/os-release | grep VERSION
VERSION="6.1 Beta2"
VERSION_ID="6.1"

Obviously the Beta2 is a beta, but VERSION_ID should work, at least for the time being. We can access that file from the unsquashed raw image, it's just going to be a bit ugly to rip it out and pass it around EIB. I'll play with some ideas.

[e-minguez]

Another option would be to make the user responsible for putting those correctly. At the end of the day it is similar to the repository string that has also a version.

[jdob]

It's an option, but IMO the last one. Once we put something into the API (i.e. image definition), it's much more difficult to remove. Until we see how many of these separate repos 6.x introduces, I'd rather not pollute the definition and have to deal with the longstanding backward compatibility headaches.

[jdob]

Update: The EIB 1.2 release will only support 6.0 and not 6.1, which means for this bug the solution is simple. Once it's resolved I'll open another to pursue the approach of deriving the URL programmatically.