On Tue, Jan 26, 2021 at 4:45 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 26. 01. 21 3:12, Kevin Kofler via devel wrote:
> Miro Hrončok wrote:
>> 1. Untested changes
>>
>> Packager pushes a "simple update" to dist git without checking if it
even
>> builds. It doesn't. Packager has no time to fix this, so they move on for
>> now. Or they submit a build but never check if it actually built.
>> Provenpackagers who need to rebuild the package need to figure this out
>> and fix the problem if it is trivial, or revert the recent commit, when
>> the failure blocks them.
>>
>> IMHO Provenpackagers should not need to worry about this. Changes should
>> be at least smoke tested by a mock/scratch build and installation check
>> before shipping them.
>
> Requiring to do a scratch build or local build before any change in Rawhide
> really does not scale. It takes too long to get anything done in that
> setting. It means 1 extra build in all cases (if it takes n build attempts
> to get a successful build, your proposed workflow requires n+1 builds
> instead of n), which can take hours.
That's why it is a SHOULD.
> The suggested alternative workflow of using self pull requests (together
> with CI on pull requests) also does not scale, it adds a lot of steps to the
> process.
Agreed.
> IMHO, the real issue is the one Robbie Harwood pointed out: It should NOT be
> a common occurrence for a provenpackager to have to rebuild a package, and
> in particular, provenpackagers should NOT do scripted mass changes. A
> provenpackager should always check what the latest package in Rawhide
> actually is before blindly rebuilding dist-git HEAD. (As a provenpackager, I
> always do that before I do anything to a package owned by someone else.)
Well, I understand your sentiment against mass spec changes, but there are
cases, where it currently cannot be avoided (e.-g. when a targeted mass rebuild
is needed for a soname bump). W.g. when we update Python from 3.9 to 3.10 we
will need to rebuild (close to) 4000 packages. How are we supposed to check what
the latest package in rawhide is and how do I act accordingly if it is not
dist-git HEAD? (Also, mass rebuild.)
Just responding to this one point (and in light of the parent's post
as well)....
...is there a way that the Python bump can be done alongside the usual
(and pre-scheduled) mass-rebuild of Fedora packages?
I realize Python release bumps are becoming a regular occurrence but
I'd rather we piggy-back off an existing deadline (mass-rebuild) than
impose other artificial restrictions.
I bring this up because, for a week, dogtag-pki was FTBFS in Rawhide
(and, your scripts caught it) but I couldn't understand _why_: my
local builds were succeeding just fine, it was only remote
scratch/non-scratch builds that were failing. It turns out to be a
change in my local pki-core (which was installed), but which wasn't
yet updated in the dependency in Fedora.
This is, admittedly, a case for simplifying PKI's deliverables (and
perhaps, make it a single source package), but still: even
well-intentioned packagers occasionally get stumped and unknowingly
push bad updates.
If we instead schedule time around mass-rebuild, I think this would
reduce stress for all parties.
My 2c.
- A
> The root cause of the issue is that we have recently had way too many
> incompatible changes in the distribution that required mass changing
> thousands of packages in Fedora. Changes such as the BuildRequires: make
> requirement, the changes to the Python and CMake specfile macros, etc. come
> to my mind. Not only do such changes introduce a need for a mass change that
> would otherwise not be there, but they also break many third-party specfiles
> that the mass-changing scripts cannot possibly catch because they are not in
> Fedora dist-git. Compatibility with existing specfiles should be a given.
The root case of this issue is that packagers push broken stuff to dist-git
(knowingly or not) and provenpackagers cannot do what they need to do. It has
nothing to do with adding "make" to BRs (which was absolutely non-invasive and
no builds were attempted). I see your point, but I don't see how "don't
make
mass changes" helps with the issue.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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