<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">There was a security feature (not sure
      it's name or if it's still supported) that required a new rpm
      feature not available in the standard CentOS rpm (file
      signatures).  The behavior of file signing was further modified by
      0001-sign-files-only.patch <br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Greg, can you comment on this?  Do the
      Debian packaging tools need to support file signatures?</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"><br>
    </div>
    <div class="moz-cite-prefix">On 2021-09-23 4:56 a.m., Zhang, Xiao
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:9a772329-a7e7-5d02-be1a-d1812c5362e4@windriver.com">
      
      <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" moz-do-not-send="true">Starlingx-discuss@lists.starlingx.io</a>
<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss__;!!AjveYdw8EvQ!JSKBRmwvSUkwkZcTuLu-pXGukX32NyAdRx0pqR5R2qqV-QEnfD-5rW41D3vY9K22BVzM$" moz-do-not-send="true">http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss</a>
</pre>
      </blockquote>
      <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>
    <p><br>
    </p>
  </body>
</html>