On Sat, 29 Feb 2020 at 16:24, Nicolas Mailhot via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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.
Can you give an example of such package?
I mean, of course, technically it is possible and not forbidden
anywhere in the guidelines as far as I know. But...
If I, as a user, see e.g. python3-alembic-1.1.0-13 in f31 and then I
will see python3-alembic-1.1.0-13 in f32 (this time with .fc32
disttag), I am going to assume nothing has changed for that package. I
think that is the intuitive user's expectation here. By providing the
same NVR (except for disttag) into the new Fedora release, as user had
installed before, I can tell to the user: "Nothing has changed for you
here". I mean, that's how I would interpret it.
If that stripped NVR suddenly starts depending on build count for the
given branch, I will start getting quite random numbers where some
package in the new Fedora release looks like "nothing has changed"
(according to its stripped NVR) but in fact a lot have changed. The
similar problem is with bumping by commit count too.
If we do these build-counter, commit-counter (without the leading
"pivot" number) approaches, then it would imho really be better to
have python3-alembic-1.1.0-fc31.13 and python3-alembic-1.1.0-fc32.13
which is quite a huge change.
>
> 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
_______________________________________________
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
