Le dimanche 19 juillet 2020 à 10:39 -0700, Kevin Fenzi a écrit :
> On Mon, Jul 13, 2020 at 10:17:11AM +0200, Nicolas Mailhot via devel
> wrote:
> > Tough it is a litteral key = value file with no fancy formatting
> > nor
> > even ini-like sections, and a handful of variables. Very boring
> > KISS
> > stuff.
> Sure, but a file with 16 spaces and a newline is pretty confusing.

I will add a line of comment instead. The confusion is due to the fact
rpmbuild wants source files to exist before the build starts, and wants
them to be more than 13 bytes. I thought filling with spaces would
convey the empty file idea, I was wrong, adding a comment is trivial
and the parsing code is robust WRT comment lines, so no biggie to
change and improve.

Thank you for the enhancement suggestion!

> But then you know that exact thing was built. 
> With this setup you look at the git hash in koji and... it's the next
> commit after that thats exactly this build? Thats really messy.

The system separates build commits from modification commits.

It’s not like right now when most commits are modification *and* build
commits, except when they are not (because the change was done in
several commits, because the build failed but git still pretends it
occured, because a branch was EOLed before the modification process
finished, because the commit tracked a build that did not pass bodhi
gating, etc etc.)

The proposed system is a lot more clear and strict, for a build to be
tracked in git it needs to have actually succeeded and be commited
back, anything else is packager WIP. Making git history something you
can rely upon.

> Right, I was suggesting _changing_ your macros for this workflow. 
> maintainer makes changes, runs scratch builds, tests, etc.
> They decide everything is good for an official build. 
> They generate the files and the macros just use those generated
> files,
> they don't bump anything or require a post build checkin.

You do not need to change the macros for this workflow, they already
support reproducible replay. Just prepare your build out of band and
then ask to build it in reproducible mode.

That only requires buildsys support to set the variable that activates
reproducible mode, and buildsys or packager support to make sure the
buildroot content matches the test builds (macros can do a lot of
things, they can not manage buildroot state in stead of the build

However what this amounts to is the following:

1. build packages in scratch mode
2. check
3. commit
4. rebuild scratch builds in reproducible mode

That is more complex than the target workflow in the macros

1. build packages
2. check
3. decide to keep the packages, and commit back

The second workflow is more reliable than the first one, because the
second preserves the packages you tested, instead of hoping nothing
changed in the buildroot between the two build steps.

Of course doing it in 3 steps requires pairing back commit with bodhi
gating, absent bodhi changes it will probably be more involved at

But the fact is it *can* evolve to a 3-step process with infra help,
and the evolution is consistent with what we’ve been trying to achieve
in the past years, and the current 4-step process is also supported at
macro level, as long as fedpkg/koji learns to set one variable (*not*
rocket science). And setting one variable is no different from the
generic bcond stuff ELN people want to happen.


Nicolas Mailhot
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to