[bug#69170] [PATCH rust-team 00/46] Add netavark

[Efraim Flashner]

On Sun, Feb 18, 2024 at 03:04:12PM +0100, Tomas Volf wrote:
> On 2024-02-18 14:39:23 +0200, Efraim Flashner wrote:
> > I pushed the patches to the rust-team branch without the change for
> > cargo-native-inputs and without the snippet for prost-build.  I also
> > adjusted some of the patches so that the packages built.
> 
> Well I am just happy it was merged, so no complains here, but I have to admit 
> I
> am curious.  Is it really expected that every user of prost-build will need to
> add protobuf into native-inputs?

Only in situations where it is needed.  In actuality we only needed it
in prost-build itself and in netavark.

> What if, in some new version, it starts requiring some-other-package instead 
> of
> protobuf?  All the downstream users will need to be adjusted as well.  That
> seems somewhat sub-optimal.  So I am trying to understand the reasoning here.

The patch you sent hardcoded the path to protobuf into the source of
prost-build, which we try not to do.  Also, using something like
cargo-native-inputs is (to me) a little "too magical" to make sure that
we have the required native-inputs in future builds.  However! Don't let
me nay-say it, if you feel strongly about it then do continue to push
for it. Ideally we'd have a true graph of the dependencies among the
rust packages rather than cargo-inputs and cargo-development-inputs, but
we still don't have anything like the antioxidant-build-system yet.

Another package which had to have an included perl dependency everywhere
was the rust-ring packages. In the end I ended up going and rebuilding
nearly all the pre-generated files in the sources so that we would have
a ready-to-use source tarball without the need for perl everywhere.
Seeing that protobuf was only needed in these two packages I don't think
prost-build needs that currently, but it's also an option.

> Thanks and have a nice day,
> Tomas Volf
> 
> --
> There are only two hard things in Computer Science:
> cache invalidation, naming things and off-by-one errors.



-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature