Let's decide which the format `dbiFindByLabelArch()` should match.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> ignatenkobrain: I don't think it makes sense to allow the disttag in
> dependencies, aka EVR. It's for the "canonical" package name, i.e. NEVRA.
Definitely it does not make sense to allow `DistTag` in dependencies because
`DistTag` shows an alternative build: generally, there is no order.
> @wladmis What do you mean by "build matching"? I'm not sure I understand what
> you're saying here...
It may be more clear by example. As there are different builds of the same
NEVR, there can be situation that two (or more) different builds can be
simultaneously installed in the system.
(Package selection is not version comparison, e.g. the package name is part of
the package selection but not of version comparison.)
(It's currently pretty hard to have to packages installed with the same NEVR,
as rpm will switch to that weird "package refresh" mode that does not do the
That is effectively what OpenMandriva Lx3 does. And that's functionally saying
that it's part of the version comparison, because you've made it a property of
selecting a package.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@wladmis What do you mean by "build matching"? I'm not sure I understand what
you're saying here...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I think probably the most sane format would be
> `name[-[epoch:]version-[release[.disttag]]][.arch]`.
> That extends nicely and overlays cleanly over most Linux distributions'
> usages of a DistTag.
I think this is bad because this would make it impossible to split
`release.disttag.arch`
On Sat, 10 Nov 2018, Jeff Johnson wrote:
> Nit picky parsing comment:
>
> The representation for "release:distag" (your example) fed to --query MUST
> be
>
> rpm --query -- -release:distag
>
> Without the leading - on release, a parser will interpret release as version,
> doh!
>
> See if
On Sat, 10 Nov 2018, Jeff Johnson wrote:
> In the interest of moving conversations about what character SHOULD be used
> as a separator for DistTag, I point you at the PCRE regex that has been in
> use for almost a decade here.
>
> http://rpm5.org/cvs/fileview?f=rpm/macros/macros.in=1.39.2.52
@imz: it's the EVR string in a separate tag, not the NEVR or NEVRA (or variants
including DistTag) identifiers where the parsing complexities (including
missing values) are hidden.
The parsing rules (which you mentioned) that splits N from the rest (in an
explicit NEVRDA) string is basically
And to be ultra pedantic for parsing a pathological string that has missing N,
E, V, and A but explicit R and D, there would need to be two dashes in front of
"release:disttag" from the rules I just described:
rpm --query -- --R:D
Yes this is a pathological corner case that assumes that
E is always (when present) a digit string followed by a colon. Trying E: first
in a greedy PCRE should resolve the ambiguity between N-E:V and N-V:D for all
but an all digit V string (which is possible but quite rare in the real world,
and easily worked around if encountered.
There are
> I think that being able to put this value in the filename can be desired. And
> it's better to have the same format, so `/` is bad.
Even if `\` bas for filenames, we can use it for the format, and separate
`DistTag` with some other symbol lile `.` or `:` in the filename. It would be
ugly, I
I should point out that there are far bigger issues than the separator if
DistTag is incorporated as a package identifier:
1) precedence of comparison: is it EVRD (as is common with %{?dist} usage) or
is it DEVR (as some might wish)
2) interoperability when mixtures of packages are installed
In the interest of moving conversations about what character SHOULD be used as
a separator for DistTag, I point you at the PCRE regex that has been in use for
almost a decade here.
http://rpm5.org/cvs/fileview?f=rpm/macros/macros.in=1.39.2.52
See the 2 (one commented out) definitions of
On Sun, 11 Nov 2018, Ivan Zakharyaschev wrote:
> On Sat, 10 Nov 2018, Jeff Johnson wrote:
>
> > I should point out that there are far bigger issues than the separator if
> > DistTag is incorporated as a package identifier:
> >
> > 1) precedence of comparison: is it EVRD (as is common with
@mlschroe: dependencies are a form of "package selection" and so DistTag will
eventually be needed in EVRD or DEVR, just like multilib arch is needed (there
are multiple RFE's and an implementation) to provide the desired specificity.
Presumably the "weird" package refresh mode you refer to is
Nit picky parsing comment:
The representation for "release:distag" (your example) fed to --query MUST be
rpm --query -- -release:distag
Without the leading - on release, a parser will interpret release as version,
doh!
See if you agree ...
--
You are receiving this because you are
On Sat, 10 Nov 2018, Jeff Johnson wrote:
> @imz: it's the EVR string in a separate tag, not the NEVR or NEVRA (or
> variants including DistTag) identifiers where the parsing complexities
> (including missing values) are hidden.
>
> The parsing rules (which you mentioned) that splits N from
On Sat, 10 Nov 2018, Jeff Johnson wrote:
> I should point out that there are far bigger issues than the separator if
> DistTag is incorporated as a package identifier:
>
> 1) precedence of comparison: is it EVRD (as is common with %{?dist} usage) or
> is it DEVR (as some might wish)
To
Most definitely short forms of N, or N-V, or N-V-R, or N.A, or N-E:V, etc are
supported by rpm queries, and not only on the CLI, but also in the API.
Adding DistTag just makes the package identifier retrieval "label" more
complicated.
--
You are receiving this because you are subscribed to
On Sat, 10 Nov 2018, Jeff Johnson wrote:
> Most definitely short forms of N, or N-V, or N-V-R, or N.A, or N-E:V, etc are
> supported by rpm queries, and not only on the CLI, but also in the API.
I understand these short forms better than the thing without a name.
Each of them makes sense to
22 matches
Mail list logo
