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.
Fabio
_______________________________________________
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
