All binaries (executables and shared libraries) are annotated with an ELF note that identifies the rpm for which this file was built. This allows binaries to be identified when they are distributed without any of the rpm metadata. systemd-coredump uses this to log package versions when reporting crashes.
+1 (as change owner)
I appreciate the improvements in the proposal. The discussion on devel seems to be still in progress so I'd like to add a temporary -1 here to avoid auto approval. Note however that I am not unsympathetic to the effort.
I don't think this provides enough benefit for the added stuff added to every ELF binary, but meh... +1
+1 here. I think it provides some advantages and the minor space usage is acceptable.
0 from me
Meh, I'm not really fond of putting more and more stuff into object files. But if this helps some developers, I won't block this proposal. 0
Let's discuss this today.
But if this helps some developers, I won't block this proposal. 0
As we discussed before, a vote of 0 is effectively a vote against, i.e. if you don't want to block, you need to vote +1 ;)
Metadata Update from @zbyszek: - Issue tagged with: meeting
Let's discuss this today. But if this helps some developers, I won't block this proposal. 0 As we discussed before, a vote of 0 is effectively a vote against, i.e. if you don't want to block, you need to vote +1 ;)
Ugh, right, this nonsense again.
I withdraw my 0 vote, and let's pretend I never saw this ticket.
There's still a subtle difference. A -1 vote requires that we hold a meeting to talk through it, whereas a 0 vote does not have this requirement.
-1
It's also a statement that "I am explicitly stating that I don't have an opinion on this" as opposed to having just missed or ignored it.
I won't be able to attend this meeting. Consider my -1 no longer existing. I still haven't been able to read all the discussion, but I don't want to actively block this on my lack of time. There's been a lot of discussion and I still want to go trough it, so I am not yet able to vote in favor either. Sorry about that.
This was dicussed during today's FESCo meeting: AGREED: Let's discuss this more on the mailing list and revisit next week.
I've read most of the discussion (although I have skipped some not-so-constructive branches).
I am +1 on the principle that while I still don't consider this super useful, others are. And I certainly do not consider it harmful.
Thanks for bearing with me.
The main problem from my perspective with this Change seems to still be the problem we had last time: it massively eliminates the benefits of RPMCoW because all the binaries are mutated on EVRs rather than on source changes.
I brought this up last time, but it seems the change authors don't care enough about the problem to try to solve it. It's rather disappointing, to be honest.
EDIT: Seems it's actually in the Change proposal now, according to @bluca...
Metadata Update from @sgallagh: - Issue untagged with: meeting - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Just for the sake of argument (because it was mentioned several times on the mailing list over the past week), what would invoking the contingency mechanism for this change look like at this point?
Targeted mass rebuild (for starts, we could probably exclude noarch packages).
Would the goal of the rebuild be to remove the note from every package, or just to fix packages that fail to build due to this change?
Remove from all packages because it's causing weird knock on effects too.
Log in to comment on this ticket.