Pity state of packaging in distro(s)

[crosser]

We use debian as the base for our production systems, and I used to make .deb packages from previous versions of pyroute2 for internal use, when we could not afford to wait for the new version to arrive in debian. It used to be pretty straightforward.

Now it's the first time that I need to do it again since the library was split in several parts. My old debianisation would not work, and I went upstream to borrow it from there. I found that they butchered pr2modules/config/version.py util/update_version.py, introduced build dependency on openstack(!) and use some openstack env variable to establish version. Basically, build-dependency on openstack prevents me from using this packaging configuration for our system.

Still, there is a real pain point here: Makefile tries to make VERSION, and it requires one to build from live git repo. An "accepted" way to execute a (at least somewhat reproducible) package build is to have a clean source tree at the start (called something_orig.tar.gz in debian) with VERSION and pyroute2.core/pr2modules/config/version.py already created, that make would not suddenly try to re-create.

So, is there a way to produce a .git-free source tree (tar), that

1. Includes VERSION and pyroute2.core/pr2modules/config/version.py
2. Has the logic of re-creating these files disabled

If there is no procedure to do that, should it be introduced? Or am I missing the point altogether, and there is a different way to cleanly build packages?

Thanks!

[svinota]

I could add version files to the tree and update them with every new tag, if it can help you with packaging.

[crosser]

I hope that I will be able to test your changes.

A sidenote: pyroute2.minimal/setup.py is in the repo, but it is covered by a wildcard in .gitignore, this is probably wrong...

[svinota]

… but there is one thing that makes me hesitating

if we leave static version files, then it will be inevitable that two different deployments from the master branch on different commits will end up having same version files and that makes me uncomfortable

[svinota]

951b1d0

Committed a solution that may fit. Pls review

[crosser]

Update the version files with every new tag

In the times of CVS and SVN there was a very useful feature to update a string inside source files on every commit. I was actually baffled when I learned that git has no plans to implement anything similar. Update on every commit would be the right way to handle it. With git, while this can be done locally, it is not part of the repo, so when other people clone the repo and start to make their own changes, information in the files will stop being updated, resulting in stale version info, as you mentioned.

It would seem that the only consistent way is to make builds two-stage - (1) to make a snapshot of the source from git, and (2) use this snapshot to build pip / distutils / deb / rpm package. The second stage should not rely on the presence of git.

As you mentioned, in the current approach, same version number will be assigned to different versions of the source...

Also, how will it work from technical perspective? Are you going to first modify the file, commit the change, and then tag? Otherwise tag will be pointing to the state of the tree where version still has previous contents...

[svinota]

So far the plan is to:

1. update the changelog
2. update the version
3. commit
4. tag
5. ⇒ check it on every CI run

Updating the version file on every commit with a pre-commit hook is a little bit overkill, I believe.

[crosser]

The current state (fc4990e) makes build nice and clean for me, i.e. I don't need any modifications on top the the snapshot of the source code from git, only the added debian directory.

But I envision that the taken approach may break for people who build the package from a git repo that is not a clone of the upstream, but repopulated/updated from a snapshot of the upstream code. They will get irrelevant version data. (Maybe there are no such people, and this is not a problem.)

[svinota]

I hope that they will let me know if they get any issues.

Regarding your build — good to hear :) Pls don't hesitate to ping me if I can help more.