On 2023-05-16 14:46 +0200, Oliver Reiche wrote: > I'm basically aware of the build dependencies > policy and all of my binary and header-only dependencies are satisfied > from packages. However, my package additionally depends on 11 proto files > (i.e., architecture-independent interface of data encoding [1]) from > google-apis [2] and bazel-remote-apis [3] as a pure build dependency. ... > 3. Taking the longer road and package google-apis and bazel-remote-apis > first. This is the right way to fix this. I noticed in 2021 whilst doing tensorflow packaging that quite a few packages were using parts of these but nearly everyone had just embedded some files. We do have parts of the api packaged (e.g ruby-googleapis-common-prootos-types, and there are also ITPs for python-google-api-core and ruby-google-apis-discovery-v1 from jan 2023) but not the whole thing for all the languages. So I started on fixing it properly, and have a build that works for C, C++, java, python3 and ruby, but some language bindings did not build, and clearly I stalled part-way through the process of fixing those. I'm not sure which bindings we actually care about and which we can leave for now. I think I started an email about this somewhere, but am failing to find it right now, so I can't remember exactly where I got to. > However, that raises a few more questions: > a. google-apis is not versioned/tagged upstream. What version would I > use? I've seen that Fedora uses the version string > "0-1.<YYYYMMDD>git<SHORT_GIT_HASH>". I used 0~0-1 to start with. 0~<DATE> is a quite a good way of versioning things like this that don't have versions. (that 0~ lets you switch neatly to real versions in the future should they appear). Adding git hashes mostly makes for unreadable versions and doesn't add much IMHO, but we can do that if it's important. > b. Where should proto files be installed to? I know that libprotobuf-dev > puts it in /usr/include, but /usr/share could be also viable. What is the > recommended location? Good question. The right answer may depend on the language. > c. As the file structure of google-apis changes rather frequently, > should there be any prefix, so multiple versions could be installed in > parallel? Debian generally tries to pick a version and make depending packages work with it, rather than try to suport multiple versions unless it really is necessary. I do not have a good feel for what the best approach here is, and would greatly appreciate input from someone more familiar with the codebase on what the best approach in debian might be. > Could you please comment on which option you would suggest to take, and > also briefly address the potential follow-up questions? I suggest we compare notes on this in a specific ITP bug for google-apis. If you have a bit of time to put into this it would be great to actully (finally) get this fixed for the general case. I can provide debian packaging and build expertise to complement your knowledge of google-apis. (and then maybe we can give bazel-remote-apis a very similar treatment). I will put my unfinished project on salsa, file an ITP, and find my notes, then mail you and we can see if we can sort this with a reasonable level of effort. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature