<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Inline comments in <font color="#3333ff">blue</font><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Scott</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 2021-09-21 9:07 a.m., Zhang, Xiao
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:91aa695a-9ef2-3945-7a73-542cd3838db8@windriver.com">
      <br>
      On 9/20/2021 9:39 PM, Scott Little wrote:
      <br>
      <blockquote type="cite">For centos, we found that loops almost
        always depend on one of a handful of low level packages, e.g.
        bash, python, gcc, rpm
        <br>
        <br>
        We had two ways to try and deal with this.
        <br>
        <br>
        1) Allow the use of a pre-compiled binary from upstream to
        satisfy the dependency when the StarlingX modification are
        unlikely to affect how dependent packages compile.  Packages in
        the 'mock' lst files could satisfy this type of requirement.
        <br>
        e.g. A=bash
        <br>
        So in your example, compile order would be:
        <br>
            F (vs upstream A), D (vs upstream A), C, B, A
        <br>
        <br>
        2) Use a different 'build-type'... other than 'std' or 'rt' ...
        when the modified StarlingX package was likely to affect the
        output of dependent packages.  Compile packages in that build
        type first.
        <br>
        e.g. A=rpm
        <br>
         = build-type 'installer' compile order would be:
        <br>
                A (vs upstream binaries) B and C ... call this
        A-intermediate
        <br>
      </blockquote>
      ? So, the 'installer' type of A doesn't depend on B and C, right?
      Just like the official method to break the loop manually?
      <br>
    </blockquote>
    <p><font color="#3333ff">[SL] I wouldn't say that A doesn't depend
        on B or C.   Rather the 'installer' package set does not build B
        or C, so they do not factor into build order calculations.  This
        does require that upstream B and C be available to satisfy build
        dependencies when compiling within the 'installer' package set.
        When compiling the 'std' set, but the packages from the
        'installer' package must be available to satisfy dependencies.
        The 'installer' compiled versions of B and C must be of higher
        version that those from upstream... and thus installed instead
        of the upstream ones.</font></p>
    <blockquote type="cite" cite="mid:91aa695a-9ef2-3945-7a73-542cd3838db8@windriver.com">
      <blockquote type="cite"> = build-type 'std' compile order would
        be:
        <br>
                F (vs A-intermediate), D (vs A-intermediate), C, B, A
        <br>
        <br>
      </blockquote>
      Seems the first one is more fit for automatic build. Then, any
      special cases thus we have to use the second method? Or we can
      always use the first one?
      <br>
      <br>
    </blockquote>
    <p><font color="#3333ff">[SL] You'll need to support both methods of
        resolving dependency cycles. <br>
      </font></p>
    <p><font color="#3333ff">Note that the layered build concept of the
        CentOS build was another way to address partitioning of packages
        into sets that might help with breaking dependency loops by not
        having A,B,C in the same compile set. Look to the 'compiler'
        layer. <br>
      </font></p>
    <p><font color="#3333ff">I think you need to support at least one of
        the 'build-type' or 'build layer' concepts to begin with.  Bonus
        points if you support both.  Supporting both was needed for the
        'rpm' package which we wanted to patch, and the patch does alter
        the format of the rpms generated, and the rpm package itself had
        to be in that format.  So rpm was compiled for build-type
        'installer' of layer 'compiler' (new rpm code in old rpm
        package), then recompiled in build-type 'std' of layer </font><font color="#3333ff">'compiler' (new rpm code in new rpm package). 
        Finally the std build of rpm was published for use by higher
        layer builds.<br>
      </font></p>
    <p><font color="#3333ff">Only designers working on packages in the
        'installer' set, or the 'compiler' layer, need to worry about
        the multi pass build.  For most packages, a single pass 'flock'
        layer, 'std' build-type, build is fine.</font></p>
    <p><font color="#3333ff">Scott</font></p>
    <p><font color="#3333ff"><br>
      </font></p>
    <blockquote type="cite" cite="mid:91aa695a-9ef2-3945-7a73-542cd3838db8@windriver.com">
      <br>
      Thanks
      <br>
      <br>
      Xiao
      <br>
      <br>
      <blockquote type="cite">Scott
        <br>
        <br>
        <br>
        On 2021-09-18 2:50 a.m., Zhang, Xiao wrote:
        <br>
        <blockquote type="cite"> Hi,
          <br>
          <br>
          <br>
          We are trying to construct basic environment for porting
          starlingX on Debian. While when I dealing with the build order
          of user space packages, the loop dependent problem blocked me.
          <br>
          <br>
          The easiest example: source package A build depend on B while
          B is also build depend on A. We can just build A, B, A, B and
          only use the later result.
          <br>
          <br>
          A fairly complex example: A depends on B and C, B depends on
          D, C depends on F, D depends on A and F. In this case there
          will be three cycles as below:
          <br>
          <br>
          A->B->D->A, A->B->D->F->A,
          A->C->F->A . Even more, if in some cases we needn't B
          or D, then we have only one cycle: ACFA
          <br>
          <br>
          I tried to find a method to deal with it but failed.
          <br>
          <br>
          So I wonder how did we deal with such loop dependent before,
          on CentOS. Any advises about it?
          <br>
          <br>
          <br>
          Thanks a lot
          <br>
          <br>
          Xiao
          <br>
          <br>
          <br>
          _______________________________________________
          <br>
          Starlingx-discuss mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:Starlingx-discuss@lists.starlingx.io">Starlingx-discuss@lists.starlingx.io</a>
          <br>
<a class="moz-txt-link-freetext" href="http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss">http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss</a>
          <br>
        </blockquote>
        <br>
        <br>
        <br>
        _______________________________________________
        <br>
        Starlingx-discuss mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:Starlingx-discuss@lists.starlingx.io">Starlingx-discuss@lists.starlingx.io</a>
        <br>
<a class="moz-txt-link-freetext" href="http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss">http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss</a>
        <br>
      </blockquote>
      <br>
      _______________________________________________
      <br>
      Starlingx-discuss mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:Starlingx-discuss@lists.starlingx.io">Starlingx-discuss@lists.starlingx.io</a>
      <br>
<a class="moz-txt-link-freetext" href="http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss">http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss</a>
      <br>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>