On Thu, Oct 28, 2021 at 2:40 PM Luca Boccassi <bluca(a)debian.org> wrote:
> On Mon, Oct 25, 2021 at 07:26:47PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>
> Thanks for revising the change proposal and filling in more details.
> After reading through it, I have some questions:
>
> 1) The proposal notes that users tend to combine built packages from
> different distributions. Even in the current environment, do we care
> about those use cases without also getting a reproducer for Fedora?
> For me, I feel that in a situation like that where a user has
> submitted a bug report that implies using a binary from some other
> distribution will lead me to ask "ok, but does this happen with the
> packages provided in Fedora? If so, how can I reproduce the problem
> locally?" So while these scenarios are described in the proposal, are
> they something that Fedora is trying to support?
There are and there will be some who do care, and whose life will be made oh so much
easier. Maybe they will be Fedora developers, or maybe they will be just Fedora users.
Maybe it's someone managing a bunch of containers, and one of them happens to be
Fedora, so it won't be you receiving the bug report, but someone else. We are trying
to enable a cross distro specification, and this is part of building a solid base upon
which others can build on. That should be enough already, no?
> 2) The proposal is built around using the package NVR to indicate
> where it came from. But those names aren't unique. In some cases
> it'll work, but in cases where the noted package cannot be found or
> has been reaped or is just otherwise unavailable, you're back to
> asking for a reproducer on a Fedora release, right? Does the NVR data
> save much work over having build-ID plus debuginfod? That's not
> rhetorical? I don't have many bug reports that are not resolvable by
> just talking through a reproducer and seeing it happen locally, but I
> know I'm not a control case.
Isn't the combination of distro name + distro version + package name + package
version + package arch enough to uniquely identify? Are there cases where there can be
duplicates in Fedora? Speaking of the Debian case, the distro version isn't even
needed, you won't have duplicates even across multiple releases.
It is not enough. It's not enough in *any* distribution, because
people can (re)build and deploy the same NEVRA. You *need* a build-id
to guarantee uniqueness of the binary. If the NVR is the same but the
build has been modified, the build-id changes.
Debian has the same problem, especially when someone uses an Ubuntu
package on Debian or vice-versa. NEVRAs are *not* globally unique.
> 3) The proposal notes making crash reporting more user-readable.
NVRs
> instead of Build-IDs, for instance. Why can't systemd ask debuginfod
> for that information for reporting? Why does this need to be embedded
> in the ELF objects? If it's a value-add, then it could happen if
> debuginfod is set up and just have it fall back on the current
> reporting mechanism.
First of all, we do not want to do network accesses from systemd-coredump, and keep any
other system accesses to the bare minimum possible. It runs sandboxed, because core files
are fundamentally unknown untrusted data, so the process doing that is restricted as much
as possible.
Secondly, internet access might be forbidden in the setup where a problem is happening.
Thirdly, maybe it's the components that allow you to do network access in the first
place that are crashing, and all you have is a serial console and desperation.
I think you've already failed at that. This would not help solve that
problem, only guarantee that you need to.
Finally, as Mark said, with this scheme you can actually enable what
you propose for the cases where it's possible, because as part of the metadata file
you can include the debuginfod URL. Please think bigger picture than single distro: maybe
the entity that created the binary uses the federated service so the build-id is enough,
but maybe it does not.
Fedora can be a trailblazer as always and be one of the first adopters (although
CBL-Mariner beat you folks for first place :-) ) but our desired goal is very much to have
this enabled cross-distro, so that a Fedora container on a Debian host or whatnot still
works out of the box.
Even if we did this, it will be a long, long, long time before there
will be interop between Fedora and Debian.
--
真実はいつも一つ!/ Always, there's only one truth!