<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><font color="#3333ff"><font color="#000000">Comments inline:</font></font></p>
    <p><font color="#3333ff"><font color="#000000">...<br>
        </font></font></p>
    <blockquote type="cite" cite="mid:0310a376-1e04-5e53-73f2-a95cd774eace@windriver.com">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>
      <blockquote type="cite" cite="mid:91aa695a-9ef2-3945-7a73-542cd3838db8@windriver.com">
        <blockquote type="cite"> <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>
    <p><font color="#400040">So? In this kind of case, we also needn't
        break the loop manually but just separate the into different
        layers/sets and compile them in different stage, right?</font></p>
    <p><font color="#400040">In the bottom logic(or, with the compiler's
        point of view), it is the same with the first one. The key
        difference comes from the special package A. It's so basic that
        it has to be compiled tice<br>
      </font></p>
    <blockquote type="cite" cite="mid:0310a376-1e04-5e53-73f2-a95cd774eace@windriver.com">
      <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>
    </blockquote>
    <p>So, in build process, we need to build "compiler" layer firstly,
      then use the new build "compilers" build other layers. Some
      special packages like "rpm" may exist in more than one
      layers/sets.</p>
    <p><br>
    </p>
    <p>BTW: I suppose the upstream rpm is already powerful enough, why
      we have to modify it? Just bug fix or new features? If the later
      one, StarlingX need some special features it hasn't? It maybe very
      useful/important for us in porting StarlingX onto other Linux
      releases.<br>
    </p>
    <p><br>
    </p>
    <p>Thanks</p>
    <p>Xiao<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:0310a376-1e04-5e53-73f2-a95cd774eace@windriver.com">
      <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 moz-txt-link-freetext" href="mailto:Starlingx-discuss@lists.starlingx.io" moz-do-not-send="true">Starlingx-discuss@lists.starlingx.io</a>
            <br>
            <a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss__;!!AjveYdw8EvQ!JaxVx_yp1y3JojCu7JAaYSFXJZa0A2Vf4-QkDC0CYX1DaaIzhT2L3HbgbprSjpA3dh1k$" moz-do-not-send="true">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 moz-txt-link-freetext" href="mailto:Starlingx-discuss@lists.starlingx.io" moz-do-not-send="true">Starlingx-discuss@lists.starlingx.io</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss__;!!AjveYdw8EvQ!JaxVx_yp1y3JojCu7JAaYSFXJZa0A2Vf4-QkDC0CYX1DaaIzhT2L3HbgbprSjpA3dh1k$" moz-do-not-send="true">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 moz-txt-link-freetext" href="mailto:Starlingx-discuss@lists.starlingx.io" moz-do-not-send="true">Starlingx-discuss@lists.starlingx.io</a>
        <br>
        <a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss__;!!AjveYdw8EvQ!JaxVx_yp1y3JojCu7JAaYSFXJZa0A2Vf4-QkDC0CYX1DaaIzhT2L3HbgbprSjpA3dh1k$" moz-do-not-send="true">http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss</a>
        <br>
      </blockquote>
      <p><br>
      </p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Starlingx-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Starlingx-discuss@lists.starlingx.io">Starlingx-discuss@lists.starlingx.io</a>
<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>
</pre>
    </blockquote>
  </body>
</html>