On 11/23/2016 08:46 PM, Andrew Daugherity wrote:

On Nov 23, 2016, at 1:08 PM, Jordi Massaguer Pla wrote:

...

Hello packagers,

we are facing an issue when updating runc. It happens that docker requires runc, but requires a very specific git commit of it. Thus, when we packaged a previous version of docker (1.12.1), we did packaged runc as

runc-1.0.0+git22222

(it was not 22222 but the commit, but this is better for explaining it, see below)

Now, we packaged a new version of docker, which requires runc to be commit 1111, thus we did

runc-1.0.0+git11111

However, zypper won't see 1.0.0+git11111 as an update to 1.0.0+git22222, but as a downgrade.

So, how to fix this?

I assume by “commit” you mean the hash? At least that’s the impression I get from the bugzilla, "0.1.1+gitcc29e3d" etc.

Since git commits are a hash and don’t monotonically increase like svn revisions, you need another way of versioning them (and I’m assuming the upstream repo doesn’t have appropriately versioned tags?). One solution I came across (sorry, I don’t remember where), and use in one of my internal RPMs that I build from a Github repo, is to use a revision count first and then the hash. Here’s an example from my php5-ffmpeg spec: ==== # To export tarball from git: # $ git archive --prefix=ffmpeg-php/ -o ffmpeg-php-.tar HEAD

# no tags currently, so use `git rev-list HEAD | wc -l`, which will always increase %define git_count 497 %define extra_ver 4609c67

Name: php5-ffmpeg Version: 0.7.0+git%{git_count}_%{extra_ver} Release: vpr0 Source: %{pkg_name}-%{extra_ver}.tar.xz ==== This requires manually updating git_count and extra_ver for each update, but upgrades always succeed. Example packages versions: php5-ffmpeg-0.7.0+git494_32e90b2-vpr0.x86_64.rpm php5-ffmpeg-0.7.0+git497_4609c67-vpr0.x86_64.rpm php5-ffmpeg-0.7.0+git501_ac3efb0-vpr0.x86_64.rpm (Not the greatest example since these hashes randomly happen to be in sorting order, but the 494, 501, etc. is what’s actually used for version comparison.)

You may need a one-time breakage (or package rename, epoch [but SUSE disallows them], conflict, etc.) to fix this, but this will give you a working version framework going forward.

I love this idea! Still I would like to rename runc to docker-runc at some point, but using your idea, we can have the git *hash* in the version which I think has more sense. Thanks a lot! jordi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11/24/2016 12:47 PM, Jan Engelhardt wrote:

On Thursday 2016-11-24 12:00, Jordi Massaguer Pla wrote:

...

...

This requires manually updating git_count and extra_ver for each update, but upgrades always succeed. Example packages versions: Ugh no. There is @TAG_OFFSET@ available for _service files, so that exactly you don't have to do it manually.

What is TAG_OFFSET ? Do you have an example? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 11/24/2016 02:22 PM, Jan Engelhardt wrote:

On Thursday 2016-11-24 13:19, Jordi Massaguer Pla wrote:

...

On 11/24/2016 12:47 PM, Jan Engelhardt wrote:

...

On Thursday 2016-11-24 12:00, Jordi Massaguer Pla wrote:

...

...

This requires manually updating git_count and extra_ver for each update, but upgrades always succeed. Example packages versions: Ugh no. There is @TAG_OFFSET@ available for _service files, so that exactly you don't have to do it manually.

What is TAG_OFFSET ? Do you have an example?

https://build.opensuse.org/package/view_file/server:mail:kopano/kopano/_serv...

What is this TAG_OFFSET doing? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org