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 רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted