Note: this was mistakenly announced as an F33 change on the mailing list. The owner corrected this in the thread.
redhat-rpm-config will be updated so users of the auto framework get automated release and changelog bumping.
Hoping that somebody will implement necessary infra changes (as pointed on the ML) is clearly no-go.
-1
I think it would be nice, in the interest of others, that you disclosed you are not a neutral party (I don’t want to dig up recent dirt, but there is enough of it an honest broker would abstain from involving himself here).
I feel completely ill-equipped to make a decision here. I don't fully understand what's going on here and I'm having trouble wrapping my brain around it.
Unfortunately, this means I'm -1 until I understand this.
If I understand this correctly (macros monkey-patching / recreating SRPM files during the build process), it sounds like a bad idea.
This is also worrisome to me:
It is not possible to reproduce a build from the SRPM as it existed at the start of last build, since that SRPM does not know the date at which the next build occurred.
It also only works for packages that use macro framework, asking to be introduced in https://pagure.io/fesco/issue/2440
With all the limitations and caveats that are presented in the proposal, I don't think we can (or should) approve this, particularly since 2440 isn't even approved yet.
You’re not understanding this part correctly, there is zero monkey-patching involved, and the main reason there are additional files involved is to avoid any form of monkey patching in the process, and separate cleanly input and output parts.
All the alternatives you’re seeing discussed on the list try to avoid the additional files requirement either by monkey-patching in place, or by hiding the additional data autobumping requires in various dark corners of the build infrastructure, creating SRPMs that do not contain the complete information needed for reproducibility or for export to other build systems.
It also only works for packages that use macro framework
Yes, sure that’s also a consequence of monkey patching avoidance. If you do not add the logic to bump within the spec (and the macros it uses), adding bumping involves injecting this logic externally ie monkey patching.
Metadata Update from @zbyszek: - Issue tagged with: meeting
Since this is for F34 and #2440 needs to be decided first anyway, I think we can postpone the discussion of this without any harm. I'll unset the meeting tag.
meeting
Metadata Update from @zbyszek: - Issue untagged with: meeting
Metadata Update from @cverna: - Issue tagged with: stalled
Metadata Update from @sgallagh: - Issue tagged with: meeting
Metadata Update from @sgallagh: - Issue untagged with: meeting
Metadata Update from @bcotton: - Issue untagged with: F34 - Issue set to the milestone: Fedora 34
@nim are you still interested to implement this change ? and are you available to provide more info to FESCO ?
It's been months without any updates. I'm going to assume this proposal is dropped and will be resubmitted later if the owner desires.
Metadata Update from @bcotton: - Issue close_status updated to: Insufficient data - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.