linkpac -c and setlinkrev behave strange

[coolo]

the current sources are defined by a srcmd5 not by a revision. Right now if you linkpac -c to a package that is a link itself, you keep the _link content but not the actual sources.

Which makes me believe that this is a bug is that setlinkrev has a -R option, which is supposed to enable the current default behaviour. There is no switch to enable srcmd5.

Beside that it would be good if both add the current vrev into the _link too - this makes sure the rebuild counters are correct. @mlschroe dislikes _links without vrev ;)

[mlschroe]

I dislike links with a srcmd5 in the rev field and no vrev. For "normal" revisions leaving out the vrev is perfectly acceptable.

[coolo]

for the reference: I'm unable to reproduce at the moment. No idea ;(

[marcus-h]

I agree that the current behavior of linkpac -c and setlinkrev is quite
confusing and misleading.
linkpac -c expands the "latest" rev of the link and sets the srcmd5 of
the expanded link as the new rev. Basically, it just "freezes" the link.

The default setlinkrev command expands the "latest" rev of link using
linkrev=base and sets the srcmd5 of the expanded link as the new rev.
IMHO, this semantics makes absolutely no sense.

So the questions are:
What does you/a user expect when doing linkpac -c or setlinkrev?
What are the use cases for a linkpac -c or setlinkrev?

[coolo]

I have only one usecase to linkpac -c: freeze the sources to what I get with osc co -e. osc setlinkrev does the same for existant links and updates already present revs.

[marcus-h]

On 2014-01-28 05:56:37 -0800, Stephan Kulow wrote:

I have only one usecase to linkpac -c: freeze the sources to what I get with
osc co -e.

Ok, that is what linkpac -c currently does.

osc setlinkrev does the same for existant links and updates already present revs.

Ok - what about the following scenario: A <- B (that is A has a _link
file that refers to B and B has no _link file).

osc setlinkrev A => set "rev" to the latest rev of B

What should a subsequent setlinkrev call do?
osc setlinkrev A
=> set "rev" to the latest rev of B or keep the current "rev"
as it is?

[coolo]

setlinkrev A should freeze the sources to the version you got at the moment you got when osc co A. So it needs to be a md5 if B is a link, it can be a plain rev if B is none.

[marcus-h]

On 2014-01-28 06:52:27 -0800, Stephan Kulow wrote:

setlinkrev A should freeze the sources to the version you got at the moment you got when osc co A. So it needs to be a md5 if B is a link, it can be a plain rev if B is none.

Ok.
setlinkrev A => sets rev="B_R1"
commit changes to B (new B rev: B_R2)
setlinkrev A => keeps rev="B_R1"

Is this the intended behavior?

[adrianschroeter]

On Dienstag, 28. Januar 2014, 07:05:16 wrote Marcus Hüwe:

On 2014-01-28 06:52:27 -0800, Stephan Kulow wrote:

setlinkrev A should freeze the sources to the version you got at the moment you got when osc co A. So it needs to be a md5 if B is a link, it can be a plain rev if B is none.

Ok.
setlinkrev A => sets rev="B_R1"
commit changes to B (new B rev: B_R2)
setlinkrev A => keeps rev="B_R1"

Is this the intended behavior?

yes, but it becomes more complicate with another indirection

A => B(rev1) => C(rev1)

if B is for example a devel package it might get updated and submitted to C (openSUSE:Factory).

So it is not enough when A points to rev 1 of B, because that one might take always the latest
version from Factory.

So, we need to use the md5sum of the merged sources, no matter how deep the link
chain is to really freeze it.

[marcus-h]

On 2014-01-28 07:13:11 -0800, Adrian Schröter wrote:

On Dienstag, 28. Januar 2014, 07:05:16 wrote Marcus Hüwe:

On 2014-01-28 06:52:27 -0800, Stephan Kulow wrote:

setlinkrev A should freeze the sources to the version you got at the moment you got when osc co A. So it needs to be a md5 if B is a link, it can be a plain rev if B is none.

Ok.
setlinkrev A => sets rev="B_R1"
commit changes to B (new B rev: B_R2)
setlinkrev A => keeps rev="B_R1"

Is this the intended behavior?

yes, but it becomes more complicate with another indirection

A => B(rev1) => C(rev1)

if B is for example a devel package it might get updated and submitted to C (openSUSE:Factory).

So it is not enough when A points to rev 1 of B, because that one might take always the latest
version from Factory.

Yes. By default, it will always use the expanded rev of B.

So, we need to use the md5sum of the merged sources, no matter how deep the link
chain is to really freeze it.

[marcus-h]

It should be fixed in commit 8b058b3.