runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

Jordi Massaguer Pla-2
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?

We thought about a solution. Since it is the version required by docker, we could fix this by renaming runc to docker-runc, and, instead of using 1.0.0+git11111 as a version, use the docker version (in this case, 1.12.3), thus our package will be

docker-runc-1.12.3

or

runc-docker-1.12.3

not sure what is semantically better ....

Then, the questions are

1- Is this a good idea? Have in mind, this is for openSUSE Leap, openSUSE Factory and also for SLE-12

2- Have you had a similar issue with another package? How did you overcame it?

3- Do you have a better idea?

Here is a link to the bug:

http://bugzilla.opensuse.org/show_bug.cgi?id=1009961


regards

Jordi Massaguer Pla


Reply | Threaded
Open this post in threaded view
|

Re: runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

Jordi Massaguer Pla-2
I am also cc-ing maintenance team at opensuse.org

On 11/23/2016 08: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?

We thought about a solution. Since it is the version required by docker, we could fix this by renaming runc to docker-runc, and, instead of using 1.0.0+git11111 as a version, use the docker version (in this case, 1.12.3), thus our package will be

docker-runc-1.12.3

or

runc-docker-1.12.3

not sure what is semantically better ....

Then, the questions are

1- Is this a good idea? Have in mind, this is for openSUSE Leap, openSUSE Factory and also for SLE-12

2- Have you had a similar issue with another package? How did you overcame it?

3- Do you have a better idea?

Here is a link to the bug:

http://bugzilla.opensuse.org/show_bug.cgi?id=1009961


regards

Jordi Massaguer Pla



Reply | Threaded
Open this post in threaded view
|

Re: runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

Andrew Daugherity-3
In reply to this post by Jordi Massaguer Pla-2
On Nov 23, 2016, at 1:08 PM, Jordi Massaguer Pla <[hidden email]> 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-<short_hash>.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.


-Andrew


p.s. My first attempt at replying was rejected by the server.  I think it was because the original message was HTML (but how did it get through?) and thus my reply automatically was, so I’m trying again with forced plaintext.N�����r��y隊Z)z{.��ZrF��x>�{.n�+������Ǩ��r��i�m��0��ޙ���������$j���0�����Ǩ�
Reply | Threaded
Open this post in threaded view
|

Re: runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

Jordi Massaguer Pla-2


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

> On Nov 23, 2016, at 1:08 PM, Jordi Massaguer Pla <[hidden email]> 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-<short_hash>.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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

Jan Engelhardt-4

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.

>> 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
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

Jordi Massaguer Pla-2


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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

Jan Engelhardt-4
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/_service?expand=1
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

Jordi Massaguer Pla-2


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/_service?expand=1

What is this TAG_OFFSET doing?


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: runc-1.0.0+git1111 is not seen as an update to runc-1.0.0+git22222

Jan Engelhardt-4
On Thursday 2016-11-24 17:19, Jordi Massaguer Pla wrote:
>>> This requires manually updating git_count and extra_ver for each update,
>>
>> 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?
> What is this TAG_OFFSET doing?

It is a number that, well, tells the offset from the last tag.

... like git_count
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]