Upstream release monitoring issue

[Richard Shaw]

I was notified by a user that a newer version of trustedqsl was available
so I looked into why I wasn't notified.

For some reason it still thinks 1.13 is the current version when it is 2.2:

https://release-monitoring.org/project/4998/

I've tried tweaking things but can't seem to find the magic formula to get
it to work.

Any suggestions?

Thanks,
Richard

[Pierre-Yves Chibon]

On Tue, Feb 02, 2016 at 04:11:46PM -0600, Richard Shaw wrote:
>     I was notified by a user that a newer version of trustedqsl was
> available
>     so I looked into why I wasn't notified.
>     For some reason it still thinks 1.13 is the current version when it is
>     2.2:
>     https://release-monitoring.org/project/4998/
>     I've tried tweaking things but can't seem to find the magic formula to get
>     it to work.
>     Any suggestions? 
I fixed it.

I had to set the name of the project to tqsl (which is the name of the tarball
anitya looks for) and the name of the sourceforge project to trustedqsl (so it
knows in which SF projects to look for this tarball).

You should have received a notification for 2.2.


Pierre

[Richard Shaw]

On Tue, Feb 2, 2016 at 4:38 PM, Pierre-Yves Chibon <pingou(a)pingoured.fr
>  
wrote:

>  On Tue, Feb 02, 2016 at 04:11:46PM -0600, Richard Shaw wrote:
>  >    I was notified by a user that a newer version of trustedqsl was
>  available
>  >    so I looked into why I wasn't notified.
>  >    For some reason it still thinks 1.13 is the current version when it is
>  >    2.2:
>  >    https://release-monitoring.org/project/4998/
>  >    I've tried tweaking things but can't seem to find the magic formula
>  to get
>  >    it to work.
>  >    Any suggestions?
>
>  I fixed it.
>
>  I had to set the name of the project to tqsl (which is the name of the
>  tarball
>  anitya looks for) and the name of the sourceforge project to trustedqsl
>  (so it
>  knows in which SF projects to look for this tarball).
>  
I almost tried that but had already given up in frustration. The
documentation is a little light and I wish it would show you the regex
after making an update without having to make it check for the latest
version.

You should have received a notification for 2.2.
>  
I did. Thanks.

Richard

[Christian Stadelmann]

Is there any reason why two packages provide tsqllib and tsqllib-devel? See
https://apps.fedoraproject.org/packages/s?search=trustedqsl and the related .spec files in
git repos?

[Pierre-Yves Chibon]

On Tue, Feb 02, 2016 at 10:45:04PM -0000, Christian Stadelmann wrote:
>  Is there any reason why two packages provide tsqllib and
> tsqllib-devel? See https://apps.fedoraproject.org/packages/s?search=trustedqsl and the
> related .spec files in git repos? 
Looks like one is using a tarball named tqsl
http://pkgs.fedoraproject.org/cgit/rpms/trustedqsl.git/tree/sources
while the other is using a tarball named tqsllib
http://pkgs.fedoraproject.org/cgit/rpms/tqsllib.git/tree/sources

But the names are clearly confusing


Pierre

[Michael Schwendt]

On Wed, 3 Feb 2016 07:34:06 +0100, Pierre-Yves Chibon wrote:

>  On Tue, Feb 02, 2016 at 10:45:04PM -0000, Christian Stadelmann
> wrote:
>  > Is there any reason why two packages provide tsqllib and tsqllib-devel? See
> https://apps.fedoraproject.org/packages/s?search=trustedqsl and the related .spec files in
> git repos?  
>  
>  Looks like one is using a tarball named tqsl
>  http://pkgs.fedoraproject.org/cgit/rpms/trustedqsl.git/tree/sources
>  while the other is using a tarball named tqsllib
>  http://pkgs.fedoraproject.org/cgit/rpms/tqsllib.git/tree/sources
>  
>  But the names are clearly confusing 
They depend on it other it seems. The review is here:
https://bugzilla.redhat.com/455396

[Richard Shaw]

On Tue, Feb 2, 2016 at 4:45 PM, Christian Stadelmann <
genodeftest(a)fedoraproject.org&gt; wrote:

>  Is there any reason why two packages provide tsqllib and
> tsqllib-devel?
>  See https://apps.fedoraproject.org/packages/s?search=trustedqsl and the
>  related .spec files in git repos? 

They used to be supplied as two separate archives which was nice because
they are versioned separately. They combined them a while back but
maintained the separate versioning which has made my spec file quite
complex and the auto bump specs always break it.

Richard

[Michael Schwendt]

On Wed, 3 Feb 2016 07:32:33 -0600, Richard Shaw wrote:

>  On Tue, Feb 2, 2016 at 4:45 PM, Christian Stadelmann wrote:  
>  
>  > Is there any reason why two packages provide tsqllib and tsqllib-devel?
>  > See https://apps.fedoraproject.org/packages/s?search=trustedqsl and the
>  > related .spec files in git repos?  
>  
>  
>  They used to be supplied as two separate archives which was nice because
>  they are versioned separately. They combined them a while back but
>  maintained the separate versioning which has made my spec file quite
>  complex and the auto bump specs always break it. 
If you're concerned about the auto bump, there are ancient ways to avoid
the breakage with a slightly changed spec file. See further below.

First of all, let me point out that giving sub-packages an own Version
and/or Release tag also implicitly redefines the %version and %release
macros for the remainder of the spec file. That can lead to complications
already and will break in customised rpmbuild environments, such as those
used by several packagers where sourcedir depends on %version.

Secondly, in trustedqsl.spec, the macro usage is not consequent enough, IMO.
In the subpkg section you rely on %version instead of your explicitly
defined %libtqslver. In the lines below, you could not access the base
package %version, because %version got redefined by the subpkg.

If you don't like using rpmdev-bumpspec, or if you don't like changing the
spec file, better stop reading here. ;-)


A first way to adjust the spec would be to insert a %baserelease value
into all Release tag definitions, either before %dist or after it and
starting at 0 or 1:

@@ -1,3 +1,5 @@
+%global baserelease 0
+
 # Because upstream is not good about bumping the library version for ABI
 # incompatible changes the Release should not be reset to 1 unless both version
 # numbers change, otherwise the NEVR of the library may cause a package not to
@@ -8,8 +10,8 @@
 # The tsql library needs to maintain it's own release version otherwise it 
 # would not be "newer" than the installed version when the application release
 # resets to 1.
-%global tqslrel 11%{?dist}
-%global libtqslrel 11%{?dist}
+%global tqslrel 11%{?dist}.%{baserelease}
+%global libtqslrel 11%{?dist}.%{baserelease}
 
 
 Name:           trustedqsl
@@ -61,7 +63,7 @@
 Version:        %libtqslver
 Release:        %{libtqslrel}
 Summary:        Development files the for TrustedQSL library
-Requires:       tqsllib%{?_isa} = %{version}-%{libtqslrel}
+Requires:       tqsllib%{?_isa} = %{libtqslver}-%{libtqslrel}
 
 %description -n tqsllib-devel
 The TrustedQSL library is used for generating digitally signed


For minor updates, simply bumping %baserelease would do the job, would not
break anything and would match the minor version bumps guidelines, too.
The solution would also survive auto bumps, because rpmdev-bumpspec does
not touch any Release tags once it bumped an earlier %baserelease or
%release macro definition.
For version upgrades, properly resetting *and* bumping your custom release
macros would be needed as with the current spec, too.


If the resulting release value is considered not readable/clear enough,
the final release values could be calculated on-the-fly:

  %global baserelease 0

  %global buildrel() %%(dc -e '%1 %baserelease +p')%{?dist}

  %global tqslrel %buildrel 11
  %global libtqslrel %buildrel 11

For rebuilds and minor changes, one would simply bump %baserelease.
For version changes, one would adjust the release macros (i.e. reset
the upgraded one to 1 and bump the other one as with the current spec,
too) *and* reset the %baserelease offset to 0 again.


A third way would be to define your %tqslrel and %libtsqlrel macros
only after the definition of the related Release tags:

@@ -8,13 +8,12 @@
 # The tsql library needs to maintain it's own release version otherwise it 
 # would not be "newer" than the installed version when the application release
 # resets to 1.
-%global tqslrel 11%{?dist}
-%global libtqslrel 11%{?dist}
 
 
 Name:           trustedqsl
 Version:        %{tqslver}
-Release:        %{tqslrel}
+Release:        11%{?dist}
+%global tqslrel %{release}
 Summary:        TrustedQSL ham-radio applications
 License:        BSD
 URL:            http://sourceforge.net/projects/trustedqsl/
@@ -48,7 +47,8 @@
 
 %package -n tqsllib
 Version:        %libtqslver
-Release:        %{libtqslrel}
+Release:        11%{?dist}
+%global libtqslrel %{release}
 Summary:        TrustedQSL library
 
 %description -n tqsllib
@@ -59,9 +59,9 @@
 
 %package -n tqsllib-devel
 Version:        %libtqslver
-Release:        %{libtqslrel}
+Release:        11%{?dist}
 Summary:        Development files the for TrustedQSL library
-Requires:       tqsllib%{?_isa} = %{version}-%{libtqslrel}
+Requires:       tqsllib%{?_isa} = %{libtqslver}-%{libtqslrel}
 
 %description -n tqsllib-devel
 The TrustedQSL library is used for generating digitally signed

The major pitfall is, of course, that while rpmdev-bumpspec would modify
all Release tags, a human packager would need to do the same (and
subpackages with an independent Version and Release aren't trivial
already).

[Richard Shaw]

I would have just made the lib a subproject but the version is higher than
that of the binary/overall version. Maybe the best thing to do is just to
go ahead and bite the bullet and bump the Epoch and do it that way.

Thanks,
Richard