On Fri, Jan 10, 2020 at 10:14:39PM -0500, Neal Gompa wrote:
On Fri, Jan 10, 2020 at 12:52 PM Vít Ondruch
<vondruch(a)redhat.com> wrote:
> Dne 10. 01. 20 v 18:33 Fabio Valentini napsal(a):
> > What about "number of commits since last version update" (possibly
> > tagged in git)? That should encompass the possibilities you listed
> > above, is well-defined, and should be most like the current behavior.
>
> That won't work. This assumes that all subpackages have the same version
> as the main package, but that might not be true (it is definitely not true
> for Ruby neither for Perl AFAIK). If nothing else, there must be way to
> override/hint the automation (unless the automation is smart enough to
> detect such scenarios, which would be cool).
>
Yes it will, because the source version is predictable. Version updates
would work off the source RPM version, and that isn't affected by games like
that.
No, it won't as we have competing %{version}-%{release} strings among multiple
packages. E.g. perl source bundles an Encode module. And we know the module
is updated frequenly on CPAN. Thus we build perl-Encode-V1-R1 from perl.spec,
then we build perl-Encode-V1-R2 from CPAN perl-Encode.spec so that R2 >= R1, then we
rebuild perl.spec again with disabled perl-Encode subpackage.
With unpredictable releases we would have to fake version of the bundled
module so that it is always lower than a version of the standalone package.
Not impossible but, a nuissance.
-- Petr