[Starlingx-discuss] [Build] CentOS-8 dnf support for modularity

[Scott Little]

Centos 8 feature branch can't currently build because dnf by default 
expects module data to be included in repo data.

A good link explaining modularity is here

     https://docs.fedoraproject.org/en-US/modularity/

It appears to be a way to groups of packages, and to support multiple 
versions of the package group from a common base os. e.g. They are 
likely concurrently supporting python2 and python3 through modularity.  
The build tooling described to support modularity is entirely centered 
around a fedora hosted build service.  My limited exploration of the 
subject has not yet found a way to build independently of the fedory 
build service.  CentOS specific documentation is also something wasn't 
able to find quickly.

Does StarlingX need to support modularity?  This needs to be considered 
at multiple stages.

1) CENGN Mirroring.

    CENGN probably needs to support modularity in it's mirroring process 
before any consideration of supporting modularity in the rest of the 
build process can be considered.

2) Download phase.

    Our downloads are currently driven by 'lst' files that state 
specific versions of a packages.  We don't use non-versioned packages, 
nor meta-packages, nor capabilities.  Modularity seems like just another 
way to map an abstraction to a set of packages, and doesn't allow us to 
control with specificity which versions of those packages we take.  If 
we wish to retain that level of control going forward, modularity 
doesn't help us download the packages we want

3) Build phase

    generate-centos-repo.sh generates a single repo from all the 
carefully selected rpms that we have downloaded.  At this stage, I see 
no need to support modularity whatsoever.



Fu Yong's update tries to support modularity within the Centos 8 feature 
branch ...

    https://review.opendev.org/c/starlingx/root/+/739883

    It appears to be re-introducing modularity at stage 3, ignoring 
stages 1 and 2.  It is using a modules.yaml of unknown origin. It names 
package we don't have. For packages that we do have, it would have to be 
kept in sync with our lst files. Keeping up with packages we build for 
ourselves is a whole other matter.  It does not live in stx-tools.  And 
at the end of the day, we don't need it to build the iso beyond telling 
dnf to not fail of module data is not found.


My proposed updates to master branch to support building Centos 7 based 
distro from a Centos 8 (or 7) build environment ...

    https://review.opendev.org/c/starlingx/root/+/762701

    https://review.opendev.org/c/starlingx/tools/+/762700

    My approach is to not even attempt to support modularity at this 
time.  We don't need it.  We can explore supporting it at a later time.