<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Linux IMA support was the name of the
      feature I believe.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">This link would seem to suggest that
      deb does not support file signatures as a standard feature ...</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">    <a moz-do-not-send="true" href="https://wiki.debian.org/Teams/Dpkg/Spec/DebSignatures">https://wiki.debian.org/Teams/Dpkg/Spec/DebSignatures<br>
      </a></div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">... although some folks might be
      working on it.</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"><br>
    </div>
    <div class="moz-cite-prefix">On 2021-09-23 10:08 a.m., Scott Little
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:31b5e238-f4d2-d53f-2aab-9d75a3cf3f2e@windriver.com">
      
      <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" 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!NfEb3E8rYS_at5letLa7sOPKvON07PJLAE62sTVmslpPDc1vllLpa9rMCVbyl3PLAbPq$" moz-do-not-send="true">http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss</a>
</pre>
      </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>
    <p><br>
    </p>
  </body>
</html>