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@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
