[Starlingx-discuss] Understanding package building order

[Cordoba Malibran, Erich]

Thanks Scott! This was a really good explanation :)


> 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-discus
> > s
> 
> 
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss