On Thu, Jan 23, 2025 at 06:57:57PM -0500, Stephen Gallagher wrote:
> On Thu, Jan 23, 2025 at 6:02 PM Simo Sorce <simo@xxxxxxxxxx> wrote:
...snip...
>
> Sorry, thanks. I forgot to note that ELN has a different %{dist} tag
> structure than Fedora. We include a "buildroot number" in the %{dist} which
> we bump before a mass rebuild. Thus, the ENVR differs by that buildroot
> number (while the rest of the ENVR remains the same). So, something like
> samba-4.21.3-6.eln145 vs samba-4.21.3-6.eln146
>
> Rawhide doesn't have that buildroot number solution, but since the
> mass-rebuild does an rpmdev-bumpspec to increase the release number anyway,
> it accomplishes the same thing.
I am not sure I understand (and sorry, it's been a very long week).
Example I am thinking of:
- foo-1.0-1.fc42 is latest in f42
- maintainer pushes a commit to update to foo-2.0-1
- maintainer builds foo-2.0-1 in a side tag, or maintainer tries to build
but it breaks for whatever reason, or maintainer builds and it gets
stuck in gating.
- mass rebuild comes along, finds foo-1.0-1 latest build in f42.
- mass rebuild bumps spec to foo-2.0-2 and builds it.
- <hyjinks as dependent packages aren't yet rebuilt>
Or do you mean it would find the foo-1.0-1 commit in git and bump that
to foo-1.0-2 and just revert the foo-2.0-1 commit?
In the end I think if we find fixing these cases too anoying/frequent,
we probibly need to look at all the existing sidetags before the mass
rebuild and tell people to merge them or adjust git or something.
kevin
--
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
