Hi, In <bd859c32-2ff7-69a7-5ddf-166efe4f0...@debian.org> "Re: Debian packaging for Arrow" on Sat, 12 Jun 2021 20:25:17 +0200, Sascha Steinbiss <sa...@debian.org> wrote:
> I checked but could not find any: searching in the Debian package index > lists nothing related to Apache Arrow [0]. Yes. I know that Apache Arrow packages doesn't exist in the official Debian repository. Sorry. I should have said that I hope that we have Apache Arrow packages in the official Debian repository. >> Could you create a "diff -ru" output between [0] and [1]? > > Sure, attached. I think some changed lines can also be reverted to your > original state, I may have oversimplified some of them during hacking. Thanks. It seems that debian/ in apache/arrow have some missing Build-Depends/Depends. > Also, are you suggesting that when you say I upload "your" Debian > package, do you mean the .debs? Because for something to get accepted > into Debian, we need to only upload _source_ packages, not binary > packages. Each package must be built on Debian servers from source. No. I wanted to say that can you reuse apache/arrow's https://apache.jfrog.io/artifactory/arrow/debian/pool/bullseye/main/a/apache-arrow/apache-arrow_4.0.1-1.debian.tar.xz to update https://salsa.debian.org/satta/arrow/-/tree/master/debian . > What do you think about the following, more established approach: Thanks for the suggestion. I don't want to mirror apache/arrow code base to https://salsa.debian.org/satta/arrow because it increases maintenance cost. And I don't want to change the upstream of debian/ to https://salsa.debian.org/satta/arrow from apache/arrow. We provide .deb not only Debian GNU/Linux but also Ubuntu. We may need some different versions of debian/ to support them. We generate debian/ dynamically instead of having some copies. For example, https://github.com/apache/arrow/blob/master/dev/tasks/linux-packages/apache-arrow/debian/control.in#L15 is used to share debian/control with platforms that have and doesn't have libc-ares-dev. And we have nightly build infrastructure against the latest master: https://lists.apache.org/list.html?bui...@arrow.apache.org https://github.com/apache/arrow/blob/master/dev/tasks/linux-packages/github.linux.amd64.yml This is useful to fix a packaging and/or code base problem as soon as possible. If we choose the following approach, > 0) You clone the salsa repository [2] locally and keep it in sync with > the version on salsa. , I think that we can't use this. > 2) You import the new tarball into your local packaging repo with 'gbp > import-orig', update debian/changelog to reflect the new version, update > debian/copyright if there are new files, refresh patches, etc. Can we copy https://apache.jfrog.io/artifactory/arrow/debian/pool/bullseye/main/a/apache-arrow/apache-arrow_4.0.1-1.debian.tar.xz contents into https://salsa.debian.org/satta/arrow to do this? > 3) You build a new package with git-buildpackage in a local chroot (e.g. > with sbuild or cowbuilder, ...) to make sure that everything builds > correctly. Can we use GitLab CI for this instead of using local machine? > What do you think? I know that this would mean moving the Debian > packaging workflow outside of your Arrow repository, but I think it > would make life easier in the long run. I have some concerns described in the above. > Another option would be that you just send me a source package for each > version you'd like to see uploaded (*.orig.tar.gz, *.dsc and > *.debian.tar.xz) and I would use that for review and upload. But then > any change that I might want to do would need to eventually be fed back > into your upstream repository, and I think we can do without the extra > round-trip if we keep everything Debian-related in one place. I thought this approach in my first e-mail. I couldn't fully describe it. Sorry. Thanks, -- kou
