On Thu, Oct 28, 2021 at 2:40 PM Luca Boccassi <bl...@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! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
