> I don't think bumping the changelog for rebuilds is actually important, but I
> do think that this is still the wrong way to solve it, because we're
> presuming that _a rebuild is important_. When rebuilds happen every day for
> whatever reason due to dependency churn, they are no longer important.
We're now straying off the original subject… but I think that this is an
interesting issue: the problem is that — especially if the rebuilds are
frequent — most rebuilds have almost no effect, but **some** rebuilds are very
important. So both extreme solutions are not good for the user: if we describe
a full history of rebuilds, then the user is drowned in a flood of boring
details, but if we make all rebuilds opaque, the user has no way to know that a
certain rebuild fixes a very important bug. For example, let's say that the
compiler was generating crashing code, and then we rebuild all 800 packages
which crash randomly at runtime. For the user, just knowing that foo-11-2 was
updated to foo-11-3 is not good enough, they really want an annotation that the
update fixes the crash, ideally with a link to a bug number, and metadata in
the update that it's a high-priority bugfix that requires a full reboot.
When we do the rebuilds manually, then we get better metadata. When the
rebuilds happen automatically, I'm not aware of any system which would inject
information about the reasons for the rebuild. But maybe there should be some
mechanism that allows this to happen. Also, maybe reproducible builds and smart
analysis of differences between binary builds can help: e.g. if an rebuild has
no effect on the payload bits, except for some version string differences, then
the update is "boring" and doesn't need to be described. (And probably doesn't
even need to be pushed to users…)
Anyway, this is all future stuff. I think we have more pressing problems to
solve ;)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1980300643
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/2880/c1980300...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
