On Sun, Feb 21, 2021 at 6:59 PM Mark Wielaard <m...@klomp.org> wrote: > > Hi, > > rpm-ecosystem@lists.rpm.org wrote: > > On Fri, Feb 19, 2021 at 09:23:58PM +0100, Mark Wielaard wrote: > > The main obstacle is that tools/debugedit.c currently depends on rpm: > > > > $ git grep -h rpm tools/debugedit.c > > #include <rpm/rpmio.h> > > #include <rpm/rpmpgp.h> > > if (rpmDigestLength(algorithm) == build_id_size) > > ctx = rpmDigestInit(algorithm, 0); > > rpmDigestUpdate(ctx, build_id_seed, strlen (build_id_seed)); > > rpmDigestUpdate(ctx, x.d_buf, x.d_size); > > rpmDigestUpdate(ctx, x.d_buf, x.d_size); > > rpmDigestUpdate(ctx, d->d_buf, d->d_size); > > rpmDigestFinal(ctx, &digest, &len, 0); > > Right. Forgot about needing a hashing algorithm for recreating an unique > build-id. This shouldn't be too hard. We can use some libiberty or binutils > code for that when we are upgrading the hashtab code. The only trickI part is > that the above let's you support arbitrary sized build-ids. But in practice > all build-ids have the same size and there are other techniques for chsanging > hash sizes. >
This is not true in practice. Go and Rust build-id's are not the same size as C/C++ ones, and it'd be a problem if we assumed fixed sizes for that. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
