<div class="gmail_quote">2011/11/23 Adam Williamson <span dir="ltr"><<a href="mailto:awilliam@redhat.com">awilliam@redhat.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> Is <a href="https://fedorahosted.org/rel-eng/ticket/4975" target="_blank">https://fedorahosted.org/rel-eng/ticket/4975</a> an example of such a</div><div class="im">
> ticket?<br>
<br>
</div>No; that's someone using the old buildroot override process. You used to<br>
have to file a ticket to request a buildroot override.<br></blockquote><div><br></div><div>Yes, I saw that. But I did not find any ticket for a "tag-specific build", so as to follow as a standard/sample procedure.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">A buildroot override is, kind of, the quick-and-dirty option: it just</div>
stuffs a build that hasn't yet gone through the update process fully<br>
into the main buildroot for a release. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">[...]</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A tag is a heavier, somewhat cleaner option: it's effectively a rolling<br>
branch (I dunno if there's a more correct term for that) of the entire<br>
release in question.</blockquote><div> </div><div>Many thanks, Adam, as it is the first time I can read an extensive explanation about that mysterious feature (at least for me) of the packaging procedure!</div><div><br></div>
<div>I think I now begin to understand the difference. BROs kind of accelerate the update process, with a temporary override of the buildroot. Whereas the specific dist tag stays forever and does not necessitate/interfere with any update procedure.</div>
<div>[By the way, if someone could point me a sample ticket for the creation of a 'boost' tag, it would be appreciated]</div><div><br></div><div>If I understand correctly, then, packages built against a specific dist tag (AFAIU, named 'target' when referring to fedpkg, as seen in <a href="https://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Building_with_fedpkg_targets">https://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Building_with_fedpkg_targets</a>), with either with koji or fedpkg, are put and stored into a specific kind-of-buildroot-on-their-own (that we can name "rolling branch"), aren't they? And, if I still understand correctly, the procedure is heavy because it imposes to maintain such a specific rolling branch, with all the packages unaffected by the incriminated package (i.e., Boost, in our case) which must be duplicated into that specific rolling branch.</div>
<div>Hence, every time an unaffected package is sent to Koji, it must be replicated into all the different specific rolling branches, right? Unless there are some lazy copy mechanism in place on the Koji and buildroot servers?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> Could we imagine extending that Buildroot Override procedure be<br>
> extended, at least on Bodhi, to ask for Rawhide specific/sandbox tags?<br></div></blockquote><div><br></div><div>If all the above was correct, one can fully understand, then, that such a feature is not desirable in Bodhi :)</div>
<div><br></div><div>Many thanks for all those explanations; I guess that a few package maintainers learn something in reading them!</div><div>I shall try to complement the Wiki pages when I am sure to have understood every detail of it.</div>
<div><br></div><div>Denis</div><div><br></div><div><font class="Apple-style-span" size="1">PS: By the way, I use the BRO procedure every time I build updates for my own-maintained (upstream) project, as "C, D depend on B, which depends on A", in my case. So, I know that procedure pretty well; but from a "client" perspective. I did not know the corresponding "server" side. And I did not understand, for sure, the specific dist tag story.</font></div>
<div><br></div></div>