[Starlingx-discuss] Understanding package building order

[Scott Little]

The default behaviour when building pkg A, is to also build anything in 
the BuildRequires of pkg A, and the requires of those packages, 
transitively until it has a full set.  It then adds packages that have a 
direct BuildRequires on A.

We do this to protect compiles in languages like C/C++ where a include 
file change in one package can have major impacts on the compile of 
other packages that uses the .h

Paranoia by default

e.g.

  A BuildRequires B and C, and C requires D, and E and F requires A

E F
\ /
  A
/ \
B C
   |
   D


so the build set is: D B C A E F.  This would also be the default build 
order for this simple case
A, E and F as cleaned to force a rebuild.
D, B and C are only built it not already built.

The unfortunate part is that RPM BuildRequires doesn't distinguish a 
source code requirement from a tool requirement.  So some packages could 
probably be excluded.  An advisory in build_srpm.data to ignore some 
dependencies is a future enhancement I've been pondering.  Another 
possibility is to only follow dependencies with -dev in the name.... not 
sure if that is 100% correct though.

BuildRequires/Requires are also littered with dependency loops. This can 
play havoc with trying to find an optimal build order. Some times it's a 
case of try to build something, and if it fails, try something else and 
circle back with a second or third iteration if at least one package 
built ok.   There were a dependency cache files in cgts-tis-repo that 
helped find good build orders, but StarlingX dropped that content last 
time I looked.  Without it, I expect the iteration counts to get quite 
large, wasting a lot of time.

One of nastiest dependency loops includes bash and the linux kernel.

To exclude E and F from our hypothetical build ...
    build-pkgs --no-descendants  A

To exclude B C D from our hypothetical build ...
    build-pkgs  --no-required  A

Finally we always add 'build-info' to the build list, and it may have 
descendants.  To suppress this ...
    build-pkgs --no-build-info A

Put it all together, for a fast build of A when dependencies are not a 
concern ... (e.g. resolving build issues internal to pkg A) ...
    build-pkgs --no-descendants --no-required --no-build-info A



On 18-07-24 12:11 PM, Cordoba Malibran, Erich wrote:
> Hi all,
>
> I'm trying to understand how the build system decides what to build on
> specific scenarios. Let's say we have a complete build and then we run:
>
> $ build-pkgs bash
>
> This will rebuild the bash package, but also the build system decides to
> delete and rebuild a set of packages that I don't understand why are
> being rebuild, for example:
>
> iptables-1.4.21-18.0.1.el7.tis.3.x86_64.rpm
> kernel-3.10.0-862.6.3.el7.35.tis.x86_64.rpm
> qemu-kvm-common-ev-2.10.0-0.tis.0.x86_64.rpm
> sm-common-libs-1.0.0-19.tis.x86_64.rpm
>
> and a big list of packages. So, the main question here is why the build system
> decides to rebuild a kernel (taking an example) in order to rebuild bash.
>
> Thank you,
>
> -Erich
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss