boost soname bump

[Denis Arnaud]

2011/11/23 Adam Williamson <awilliam at redhat.com>

> > Is https://fedorahosted.org/rel-eng/ticket/4975 an example of such a
> > ticket?
>
> No; that's someone using the old buildroot override process. You used to
> have to file a ticket to request a buildroot override.
>

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.


A buildroot override is, kind of, the quick-and-dirty option: it just
> stuffs a build that hasn't yet gone through the update process fully
> into the main buildroot for a release.

[...]

A tag is a heavier, somewhat cleaner option: it's effectively a rolling
> branch (I dunno if there's a more correct term for that) of the entire
> release in question.


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!

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.
[By the way, if someone could point me a sample ticket for the creation of
a 'boost' tag, it would be appreciated]

If I understand correctly, then, packages built against a specific dist tag
(AFAIU, named 'target' when referring to fedpkg, as seen in
https://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Building_with_fedpkg_targets),
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.
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?

> Could we imagine extending that Buildroot Override procedure be
> > extended, at least on Bodhi, to ask for Rawhide specific/sandbox tags?
>

If all the above was correct, one can fully understand, then, that such a
feature is not desirable in Bodhi :)

Many thanks for all those explanations; I guess that a few package
maintainers learn something in reading them!
I shall try to complement the Wiki pages when I am sure to have understood
every detail of it.

Denis

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20111123/53aadec7/attachment.html