Hi Adam,
Thank you so much for replying, it helped a lot!
--
Best regards,
Beatriz
Santa Catarina State University - UDESC
Em dom., 20 de jun. de 2021 às 03:45, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> escreveu:
On Sat, 2021-06-19 at 13:53 -0300, Beatriz Michelson Reichert wrote:
> Hi Adam, thank you for replying, it helped a lot!
>
> I have some more questions about the composes and Koji, and would like to
> know if you could help me with the questions about this subject too:
>
> 1. What repository does Koji forward the build of a package and the RPMs
> to?
> 2. The nightly compose process receives some package builds as input.
> What repository are these builds in? Is it the same repository as the
> previous question?
> 3. The candidate compose process receives the candidate packages (stable
> packages) as input. What repository are these candidate packages in?
Hi Beatriz! So these questions are sort of...backwards, in a sense. The
compose processes are what *produce* the repositories. Koji doesn't
exactly build packages and then put them in a repository.
Well, technically there is a repo metadata 'view' of each Koji tag. You
can find those at kojipkgs.fedoraproject.org/repos/ - each tag has a
directory there, and you can find repodata under each directory which
gives you a repo 'view' of the latest builds for that tag. But those
are not things that are really intended to be consumed by Fedora users
or testers in most typical workflows.
I think the best way to think of it in terms of how most processes work
is that Koji builds packages and then they just sort of...sit in Koji
to be used as inputs to other things. A "compose" is the mechanism by
which we take builds from Koji and produce the things that Fedora users
'consume', including images and the formal public-facing repositories.
So, just running a build in Koji does not necessarily result in it
appearing in any conventionally-public-facing repository. For Rawhide
there are some convenience mechanisms hooked up so when a packager does
a build the "usual" way, it automatically gets tagged for Rawhide and
included in the next compose, but even that can be avoided if desired.
For a build to appear in a public repo, some kind of compose step has
to happen in between.
To answer q2 directly - the nightly compose process for Rawhide and
Branched uses the packages tagged with the stable tag for the release
in question. So currently Rawhide composes use all packages tagged
'f35'. When F35 branches, Branched composes will use all packages
tagged 'f35' and Rawhide composes will use all packages tagged 'f36'.
The composes that are run regularly to update the stable release update
repositories use the '-updates' tags - so when we run a compose to
update the F34 stable updates repo, for instance, it uses all packages
tagged 'f34-updates'. (There are also composes run to update the
updates-testing repositories for stable releases and Branched; these
use the 'fXX-updates-testing' tags, not surprisingly). When a stable
release update is "pushed stable" via Bodhi, what actually *happens*
that makes it ultimately show up in the public stable updates repo is
that it has the 'fXX-updates' tag applied to it in Koji, so the next
stable update compose run pulls it in. (For Branched and Rawhide, when
an update is 'pushed stable' via Bodhi, it has the fXX' tag applied, so
the next nightly compose pulls it in).
Note that your q2 and q3 are phrased slightly wrong, btw. It's nightly
composes that use "[all] stable packages" as input. Those composes are
automated and use *only* the packages tagged 'f35' or 'f36' or
whatever. Candidate composes can potentially pull in additional
packages. The difference between a candidate compose and a nightly
compose is some slightly different naming, configuration and metadata
produced by running the compose tool differently, *plus* the potential
to manually include packages that have not yet been 'pushed stable',
which is done by releng by hand. Here's an example from the last
release:
https://pagure.io/releng/issue/10093#comment-729024
that was the candidate compose request I filed that resulted in F34
Final RC2 being built, which is ultimately what was released as F34
Final. As you can see, I listed 9 updates to be included in the compose
which were not 'stable' at the time. The automated nightly compose run
on the same day would not have included those updates. In order to
include them, releng would have tagged them into a side repository that
is included in the candidate compose configuration before running the
compose. I actually forget what that repo is called :P Again, mboddu
could tell you. All of the above is my best recollection/understanding,
btw - if Mohan or Kevin Fenzi tell you something different, they're
probably right.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
