Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
>
> What about fedpkg local and fedpkg verrel then?
Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
detached file state means that fedpkg local (or checking out git state
and building in mock or copr or OBS or via plain rpmbuild -bs) will
give you the same result as launching fedpkg build. Which is exactly
what you want to make QA and testing workflows work. Those don’t live
exclusively in koji.
And because only production builds get committed back the packager can
change his mind and stage a few more changes before doing the
production build, without polluting the changelog builds that were
never pushed to users.
For fedpkg verrel you'll probably want to output a last (saved in
detached file) and next line (probably factorizable by externalizing
the dynrel bump logic in a separate command). That’s more honest
anyway, next may happen or not, when you launch fedpkg verrel, it’s
mere potential (the next commit may bump version and invalidate your
future build).
> As for changelog, generally with build system commiting back to
> dist-git, there is a problem that I can be concurrently pushing
> changes while the build system tries to push its changes and build
> system is not human so it will not know how to resolve such
> situation.
I understand, but that’s the consequence of automating changelog. Right
now the reconciliation is done by the human packager (you can get in a
similar situation by working on a change at the time a mass rebuild
runs).
> Do you have a solution for situation when I launch a build and then I
> do another change, commit, and push (the changes to changelog can be
> quite arbitrary here)?
You can set a lock at fedpkg build time, and forbid fedpkg commit in
that branch till the lock is released (fedpkg build in the branch
succeeded or not). The packager can still git commit things, as long as
he does not touch the detached changelog file. Only fedpkg commit syncs
git state with detached changelog state.
An alternate simpler strategy would be to mark the fedpkg build as
failure in koji if sync-back failed. That would work too. The build
system need not be ultra smart, just robust WRT human behaviour.
(If the packager deliberately messes with the detached changelog while
a production build for the same branch is ongoing he deserves a build
failure – the changelog state is undefined till the build ends, so he’s
doing changes on quicksand. If he tried that today he’d probably have
to rewrite his changelog if the build failed)
> I think, this is not a decision of rpm upstream but an infrastructure
> thing or a mock thing.
mock and rpm upstreams excel when they work together. My premise is
that they are better qualified than us to do rpm/buildsys boundary fine
tuning.
Populating changelog from git and syncing back to fedora git are
fedpkg/koji responsability, because Fedora git is Fedora specific
infra. Handling release autobumping and build recording belongs to the
lower layers, however. They’re the same with or without Fedora git,
they belong to lower levels.
> I think your proposal wouldn't quite work for copr because it has no
> access to those repositories (which especially for src.fp.o is good
> in your proposal, otherwise copr would be modifying src.fp.o repos).
copr does not need write access to Fedora git, its builds do not
participate to the production build lineage as long as no one re-
imports them in koji (which should be a deliberate fedpkg command, not
something driven by copr itself).
copr only needs access to its own private git to remember its own last
successful build, if people want it to autobump from last successful
state. (maybe they don’t). srpm import in copr will overwrite copr
state with the state the new srpm contains, which is fine too.
Putting state in detached srpm source files has the following super-
duper property. You can import the srpm or scm checkout between
systems, and they’ll just pick up from the point the previous system
left things, without needing a full scm import. So you do not need to
deal with incompatible scms (or lack of scm).
> So if someone wanted to have a build counter in the release, yes,
> this could be an implementation although it would be much easier to
> simply catch the information from copr's database where this info is
> stored
It is simpler from the buildsys POW, but it ties state in a specific
git and buildsystem. So it will break cross-buildsys workflows.
Cross-buildsys workflows are critical for the project success because
they enable sharing work with other distros, and allow packagers to
make the best of a palette of build systems (each with its own
constrains and limitiations). Fun fact: I noticed today than one of my
old Fedora packages was rebuilt by others for AIX. This kind of cross-
pollination is one of the strengths of the rpm ecosystem. Don’t break
it by making out packages depend on Fedora git or buildsys state.
> in fact there would never be a changelog file at
> all because nobody uses fedpkg commit in git repos that are not from
> src.fp.o so this dynamic changelog thing wouldn't be usable for copr
> at all.
When using a buildsys that didn’t automate changelog filling, you can
just write in the detached changelog file directly. The build part
won’t care how you filled this file with changes, it just needs it to
record a build point.
scm to changelog plumbing logic is going to change over time (for
example, if we drop pagure for gitlab, or git for the next best thing).
It is dangerous to set it in stone.
dynrel autobumping and recording builds in the changelog is more of an
rpm format change. It can (and should) be done in an independant way.
Regards,
--
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
