Le samedi 29 février 2020 à 15:12 +0100, clime a écrit :
> On Sat, 29 Feb 2020 at 14:47, Nicolas Mailhot via devel
> <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > Le samedi 29 février 2020 à 14:28 +0100, clime a écrit :
> > > Does ENVR without %{dist} means something with respect to the
> > > content
> > > from
> > > which the package was built or with respect to features that it
> > > offers for the given distribution version?
> >
> > You need to evaluate evr with a neutral dist value to decide to
> > bump or
> > not the auto-dynamic part of release or not. Because the whole
> > point of
> > the auto-dynamic part of release would be to track rebuilds from
> > the
> > same spec, all othert parts of EVR being equal
> >
> > Changelog-side and package build side you need the full EVR without
> > neutralization
>
> Thank you very much Nicolas but you reacted to a question which was
> actually unrelated to your proposal. That particular question about
> the meaning of ENVR when you strip the distribution tag (i.e. .fc32
> or
> .el7) was intended to be generic, i.e. i want to know how if e.g.
> python3-alembic-1.1.0-1 has any meaning alone without, for example,
> .fc31 appended to it (or if it should have any meaning which is e.g.
> not respected these days).
And I answered you. From a changelog POW you need the full dist because
the exact same stripped/neutralized Release may (and does) exist today
in different branches, pointing to different spec states.
>From a dynamic release POW dist is irrelevant to compute the next bump
point and needs stripping. All that matters is that the result evrs
differently, ignoring dist. Keeping branches synchronized or not is a
packager decision (choosing to desync requires specific upgrade path
care, but it is a valid use case today).
And yes that info oriented my proposal. Any other proposal will have to
take it into account too.
Regards,
--
Nicolas Mailhot
_______________________________________________
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
