Le samedi 29 février 2020 à 20:57 +0100, clime a écrit :
> 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...
That’s pretty much inevitable when you hit release-specific problems
that require pushing release-specific changes or patches in one or
several branches. No matter what clever numbering conventions you try
to invent, things are eventually going to collide.
%{dist} is not here just to prettify things. Branching is real
branching. syncing branches is a packager optimization. It’s not
possible in all cases. The only hard requirement is to keep evr lower
in older branches, syncing is optional and not done when it’s just a
lot of pain for little win.
You can say “start from the -devel evr, add .number when adding a
patch”. That only gets you as far as the first patch. What if f33 state
needs patching one way in f32 and another in f31 (ignoring el7 and el8
for now)? Your convention already hit its limits. And it’s just the
first patch step.
The usual packager reaction in that case is either add spaguetti dist
ifdefs in their spec, or just give up on syncing (I definitely prefer
the second strategy). After all, no harm done if the branches de-sync,
as long as cross-release upgrade pathes work.
> 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.
And you’ll be wrong, because we do branch. I we could have avoided
branching, we’d have avoided it. Branching brings quite a lot of
complexity. However we do branch because releases overlap but are not
technically equal.
What we *can* do is make fedpkg merge master work to avoid packager
work when the branches can be synced (or re-synced). And fedpkg merge
master should work with my proposal (as long as the older branch has
not already autobumped further than master, but a packager that allows
that already broke the upgrade path, and earned manual clean-up work).
> 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.
The system provides a %{dynrel} counter. The packager can stick it
before or after %{dist} (or not use it at all), the mecanism will work
the same (obviously, without autobumping if the packager does not use
%{dynrel} in his release string).
%{dynrel} is sufficient to handle autobumping. If you try to own the
whole release string, you’ll hit all kinds of complexity (starting with
pre/post release, then the ruby thing, etc)
%{dist} (especially taking %{distprefix} into account, but even without
it) does not sort well. elx/fcx does not sort. Third part packages may
use a sort-able dist or not. if you want evr to work, you put the
relevant part of r before dist, and keep it only as last resort to
distinguish between synced fedora branches.
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
