Attribute "on_scr_cd" has no effect when binary and source package name differs

[martin-29]

When the source package has a different name than the corresponding binary package, the current implementation (resolving source package name and then decide to ignore/add the source package) can make the on_scr_cd attribute useless.

Real world example:

I have the following three binary packages in my pkg-list, where the on_src_cd attribute is required because the repository holding these packages doesn't contain any source packages.

<pkg on_src_cd="False">mender-auth</pkg>
<pkg on_src_cd="False">mender-update</pkg>
<pkg on_src_cd="False">mender-flash</pkg>

Normally that would work, but in this case each of the packages containing a reference to the source package mender-client4.

Below the details for one of the binary packages as reference:

Package: mender-update
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 3670
Maintainer: The Mender Team <[email protected]>
Architecture: arm64
Source: mender-client4
Version: 4.0.4-1+debian+bookworm
Depends: mender-auth, libarchive13 (>= 3.3.3), libboost-log1.74.0 (>= 1.74.0+ds1), libboost-thread1.74.0 (>= 1.74.0+ds1), libc
6 (>= 2.34), libdbus-1-3 (>= 1.9.14), libgcc-s1 (>= 3.0), liblmdb0 (>= 0.9.7), libssl3 (>= 3.0.0), libstdc++6 (>= 11)
Recommends: mender-flash, mender-setup
Conflicts: mender, mender-client
Conffiles:
 /etc/mender/inventory/mender-inventory-bootloader-integration d9d86b3140729124db9090fb95ed4093
 /etc/mender/inventory/mender-inventory-hostinfo fd527135109d7056767e03f050784c89
 /etc/mender/inventory/mender-inventory-network 3bb536bc6e021ae84ff30209b00c4d1c
 /etc/mender/inventory/mender-inventory-os 58484ae7d9d87eb03921de3c8a901304
 /etc/mender/inventory/mender-inventory-provides 05063926e9892b2774fe7cfe5d2528a4
 /etc/mender/inventory/mender-inventory-rootfs-type d77b4ed7a3c706e826d6734154cb007a
 /etc/mender/inventory/mender-inventory-update-modules ecdb1a9990762403e3e5157147779bf2
 /etc/mender/scripts/version eccbc87e4b5ce2fe28308fd9f2a7baf3
Description: Mender update
 Mender-update is an open source over-the-air (OTA) software updater for embedded Linux devices.
Homepage: https://mender.io

That leads to the error during the build when trying to create the source CD-ROM:

[ERROR]No sources for package 'mender-client4-4.0.4-1+debian+bookworm': No source found for mender-client4_4.0.4-1+debian+bookworm

Adding the package mender-client4 to the package list doesn't work, because it would install some unwanted additional packages.

As far as I understand it, the problem is caused by the order of the steps.

The function get_corresponding_source_packages, which resolves the source packages to each binary package, does that before add_source_pkg is called, where the comparison of the forbiddenPackages list (containing the binary package names) then doesn't match anymore.

Therefore, the question if there is a way to adapt that logic, so that for example the forbiddenPackages list contains not the binary package name but instead the already resolved source package name?
Or alternatively moving the logic of comparing the list to the get_corresponding_source_packages function, so that the components list passed to the mk_source_cdrom function, doesn't contain source packages, which are referenced by a binary package with that attribute, at the first hand?
Another approach I have in mind, which would be at least for me ok, is to have an additional property to blacklist specific source packages.

Do you know, if one of the approaches is feasible or if there are any other approaches to tackle that problem?

[martin-29]

I opened a PR (#419) which resolved the issue for me.

At a glance the binary names in the forbiddenPackages list will be resolved by the existing get_corresponding_source_packages function and a second list forbiddenSrcPackages will be created with unique source package names which are then used for the comparison inside add_source_pkg.

Works if binary name and source name match, like previously, but also if they don't match.

Can you give me feedback if this is sufficient for you or if there is a better approach?

Best regards

[t-8ch]

Thanks for the report.
Let's continue this discussion over on the PR.

The general approach looks good, but some details need to be adapted.