Hey Miro!
On Fri, 2020-04-10 at 11:01 +0200, Miro Hrončok wrote:
> On 10. 04. 20 1:50, Miro Hrončok wrote:
> > On 09. 04. 20 23:57, Miro Hrončok wrote:
> > > On 09. 04. 20 20:45, Pierre-Yves Chibon wrote:
> > > > I actually cannot comment on this, it may be worth opening a
> > > > koji ticket to ask
> > > > if this is the case or not and if it is if they can think of a
> > > > way to deal with
> > > > this.
> > >
> > > I plan to test this in staging and follow up on that, but
> > > possibly after Easter.
> >
> > I was curious:
> >
> > https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=90028113
[snipped errors from broken Python 3rd party packages]
> So there are 2 reasonable things I think that can be done apart from
> rewriting rpmautospec into Rust ;)
It's a little late for April Fools. :)
[snipped the "special case buildSRPMFromSCM for side tag builds"
approach]
> ## Move (most of) rpmautospec outside of the mock chroot
>
> Another solution I can think of is that the koji-builder-plugin-
> rpmautospec
> package does all the nice things like figure out what to inject into
> the spec
> file and prepares everything for needed for rpmautospec *outside of
> the mock
> chroot*.
>
> rpmautospec than in fact would only be responsible of actually
> putting the
> information into the specfile without using all the 3rd party Python
> libraries.
> It would be a simple script (see fedpkg-minimal that exists for this
> very
> reason) -- keeping it in written in Python remain an option (as long
> as it only
> uses stdlib and doesn't live in site-packages), but making it Bash
> (like
> fedpkg-minimal) would be even less fragile.
>
> However, what are the reasons to determine the spec content from
> within the
> buildroot? Does it heavily depend on values of macros like %fedora or
> %dist?
>
> What parts of the procedure are safe to do from a different system
> and what
> needs to be done from within?
>
> Pros:
>
> 1. Much more robust solution, smaller package footprint in
> buildSRPMFromSCM
> means smaller "bungle surface" (like "attack surface" but without the
> ill will).
>
> Cons:
>
> 2. Significant (design) changes in rpmautospec needed.
> 3. I don't know the exact reasons rpmautospec runs from within the
> chroot.
I think rpmautospec separates concerns between what has to be done in
the build root vs. what can be done outside pretty good already. ;)
Let me back up a little:
The reason rpmautospec does anything in the build root at all is
because the code that computes the "next release" value has to know for
which Fedora version (or more precisely, the %dist tag) the build in
question is intended: if at all possible, the EVR about to be built
should fit within that of the latest builds in the same or older Fedora
versions on the one hand, and newer Fedora versions on the other.
Unfortunately (for rpmautospec), Koji doesn't really care about the
Fedora or EPEL version it's building for, all it seems to know is tags
and how they're derived from each other. The dist tag is only set in
the build root, by /usr/lib/rpm/macros.d/macros.dist from the fedora-
release-common package.
Fortunately, rpmautospec already does very little in the build root:
The plugin queries Koji outside (this is where the one 3rd party Python
package dep comes from) and stores the information gathered (latest
build EVRs for each dist tag) as git tags. The code run in the build
root computes the next release using the tags (dep on git-core), and
with that generates the changelog (which needs info about the current
and historic build EVRs).
So, to make this more robust against problems like you described, we
should decouple what's run in the build root from a specific minor
version of Python and the rpm Python package (and remove the
superfluous Koji dependency). This shouldn't be much work, the biggest
piece is probably to make it get by without using the rpm Python
package (for comparing EVRs and to expand macros), but a tiny ctypes
wrapper around rpmlib should solve this for us.
To me, that's good enough. Porting the pieces that have to run inside
the build root to e.g. shell really wouldn't make them more robust, but
just change one dependency which may not break for another.
Also, even if the worst came to the worst, say a severily broken Python
or git-core package has snuck its way into the build roots, and all
people with the power to untag these went on vacation, then any
packager can easily unblock their build by temporarily reverting to a
manually set release and changelog, the plugin will just go out of the
way in this case.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
