On Mon, Jun 20, 2022 at 6:28 PM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
>
> On Tue, Jun 21, 2022 at 12:15 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> >
> > On Mon, Jun 20, 2022 at 3:48 PM Zbigniew Jędrzejewski-Szmek
> > <zbyszek@xxxxxxxxx> wrote:
> > >
> > > On Sat, Jun 18, 2022 at 01:05:31PM +0200, Aleksandra Fedorova wrote:
> > > > The most visible impact of the proposal would be the filename change:
> > > >
> > > > Current: dnf-4.9.0-12.fc36.noarch.rpm
> > > > Proposed: dnf-4.9.0-12.fc36.34897715.noarch.rpm
> > >
> > > The history of development of rpm and the ecosystem has shown that
> > > modifications that are visibile at the level of the output binary rpm
> > > have a long implementation tail for the ecosystem. In particular, if
> > > we allow add the build-number information, many many consumers will
> > > need to adjust for this, from trivial things like regexps to match
> > > '%dist.rpm' in the filename to complicated things that extract and
> > > make use of the version field. So if we want to add a new feature
> > > here, a much strong justification why what we have already is not
> > > enough would need to be provided.
> > >
> >
> > This is already something people have to expect, since our existing
> > policy permits a tailing number and it is used for various purposes.
>
> Well, it's complicated.
>
> There's currently a 100% foolproof way to parse NEVRs into their
> components, because there are *always* two "-" separators (when
> counting from the end) that separate "name", "epoch:version", and
> "release" (i.e. you can do nevr.rsplit("-", 2) in Python, and you get
> 100% correct results for 100% of packages in Fedora repositories).
>
> If anything, the "Build" tag should be separated by a hyphen, not by a
> dot, because that makes it look like it's part of the Release tag or
> the %dist macro (i.e. it should be N-E:V-R-B, not N-E:V-R.B).
>
> However, by adding another component to the end that's also separated
> by a hyphen the fool-proof parsing breaks catastrophically, and you'd
> have to fall back to (possibly incorrect) heuristics for checking
> whether the NEVR has three components or is in the new NEVRB format.
>
> But separating the Build tag from the Release tag by a dot as
> suggested in this proposal would similarly fail to parse unambiguously
> - because you can't know whether it's a weirdly high post-%dist
> Release increment, or an actual Build tag, as they would both be
> valid, convey different semantics, but result in a string with the
> same syntax.
>
The rule is already violated when you evaluate the full NEVRA.
Changing it to NEVRABA doesn't make it significantly worse.
If it were up to me, I'd rejigger things to have NEVRBDA instead:
name-epoch:version-release.build.disttag.arch. However, doing such a
thing has more consequences for the semantics of version comparison.
I've seen and worked with EVRD before, and it's quite handy, but
that's not an upstream thing.
EVRB would be more useful since it solves concrete issues we have
right now for rebuild management (note not *tracking* which is
something I explicitly don't care about). We can choose to use a dash
to separate release and build, or keep using a period. It doesn't
matter to me one way or another.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
