> On Thu, Oct 28, 2021 at 2:40 PM Luca Boccassi <bluca(a)debian.org&gt; wrote:
> 
> 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.

Maybe I'm misunderstanding the use case, but in Debian when a build of the same 
source is done again (eg: library ABI transition), the revision gets +bX 
appended, so the metadata changes. I know Suse does the same on OBS, there's 
both a build counter and a source checkout counter (ie, download the same 
source twice and it gets an incremental revision).

But anyway, the build-id doesn't go anywhere anyway? It's there and collected 
too by systemd-coredump/coredumpctl.

> I think you've already failed at that. This would not help solve that
> problem, only guarantee that you need to.

Well we use this system internally at $work already, so I know for a fact that 
it does help. In some cases one has the luxury of being able to ignore bug 
reports, in others, not so much.

> Even if we did this, it will be a long, long, long time before there
> will be interop between Fedora and Debian.

Of course, that's understood. It's going to be a long and difficult road.
_______________________________________________
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

Reply via email to