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). -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
