[packman] audacity-Version für 11.4 etwas zu alt

[Cristian Morales Vega]

2011/3/13 Christian Boltz <packman at cboltz.de>:
> zypper dup proposes to change audacity from packman to the openSUSE
> package version (I'm using 11.4 64 bit).
>
> zypper dup output: (shortened)
>
> The following packages are going to change vendor:
>  audacity              1.3.12-8.pm.64.1 -> 1.3.12-12.1        x86_64
>     Main Repository (OSS)  http://packman.links2linux.de -> openSUSE
>
> Changing the -8.pm to -13.pm should fix the problem.

I would argue Packman shouldn't try to have highest release numbers:
- zypper dup installs the package from the repo with the highest
priority, the version (and release number) is ignored. Only if the
priority is the same the version-release matters.
- zypper dup is not recommended (no GUI app allows to do it, zypper
shows a warning, etc.). "zypper dup --from" is what's expected from
users. (but OK, I do "zypper dup" all the time)
- In the OBS people doesn't cares about release numbers, they are
generated automatically, so links are going to have problems.

I would highly recommend to configure priorities in a way that makes
sense to you and then use locks for specific cases.

> Detlef's reply:
>
> We can't really change that, the package is a link to OBS
> multimedia:apps. We just rebuild it with the right codecs ;-)

In fact Packman Build Server has more control about this than I have
in the OBS, I will explain later.

> My reply then was that the packman _link contains a fixed baseref, which
> Detlef removed in the meantime. Unfortunately this didn't fix the
> problem as far as I can tell.

OK, the way links are handled was, the last time I checked, quite
complex for something you would expect to be simple; and not very
documented. But...

To start with, the Packman BS has a custom release number scheme. I
would expect it to be shown with "osc -A packman meta prjconf
Essentials | fgrep -i Release"... but it's not there. Anyway, from the
audacity result I understand the scheme is the equivalent of having

Release: %%{?release_prefix}.pm.<CI_CNT>.<B_CNT>

in the Essentials prjconf. So it uses the release number from the spec
file, release number that is ignored by most OBS packagers.
I could change the

Release:        8

for a

Release:        13

in the OBS (in fact no, I can't, but I can create a submitreq). But
that would not solve much since a minor fix in the OBS's audacity
package would change it's *published* release number... and since
packagers there don't change the *spec file*'s Release value, Packman
would maintain the same published release number.
I could change it for

Release:        100000000

But I don't really know the details about how the OBS generates the
release numbers. I think it uses the spec file release number *plus*
the checkin count (but not always?) so the problem would be even
worse. This "magic" way the OBS has to handle release numbers, that
nobody 100% understands, is part of the cause packagers just ignore
it.
Also, at some time the package will start to use the "set_version"
service. And that service always sets the spec file's release number
to 0.



How link packages handle it? They for sure want a highest release
number than the original package!! Well, because there is some
specific control about the release number of link packages (see osc
link "-C" option). The link file can have a "cicount" option that can
have three values: add, copy, and local.
Add: Add over the original, so the link package always has a greater
release number. It's the default.
Copy: Use the same release number than the original
Local: Ignore the fact it's a link and use normal rules.

That's why the Packman package has a release number of "8.pm.65.1":
- 8 because that's what the spec file says.
- 1 because it's the first build with 65
- 65 because the original package has 60 + 1 + 4. Being 4 the number
of changes that have been in the Packman BS.

In Packman hadn't changed the release scheme the release number would
have been just "65.1", always higher than the original. If we want to
keep the ".pm." thing we could use:

Release: <CI_CNT>.pm.<B_CNT>

or

Release: <CI_CNT>.<B_CNT>.pm

But IMHO anything that uses the spec file's release number, specially
as the most significant part, is going to break with links to the OBS
(CCing Pascal, he perhaps even fully understands OBS release numbers)


Now, about the baserev thing... I neither am sure I understand it xD
The link file can have a "rev" parameter that specifies an specific
version, that's what I suppose Detlef though "baserev" was doing. But
a link file with a baserev parameters still always links to the latest
version of the original package.
I think a link with a baserev parameters is not a link (osc linkpac)
but a branch (osc branch). The baserev would specify the "original
file" for diff3 to do its work. Now that it has been removed diff will
be used instead of diff3 (I don't really know the details) so it's
easier that the package breaks because of conflicting changes between
the OBS package and changes done locally in Packman... Probably
Packman never will need a local change for audacity so it makes no
difference :-)