@ffesti converted this issue into discussion #2845.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/589#event-11498460864
You are receiving this because you are subscribed to this thread.
Message ID:
I don't have a problem with it if @pmatilai and @ffesti are okay with it.
But the filename should use a dash instead of a colon to avoid issues with
parsing file paths.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@Conan-Kudo recently I take a brief look at OpenMandriva Lx3. It uses
`%name-%version-%release-%disttag%distepoch.%arch.rpm` for filename, each of
its rpm package provides `name =
%|epoch?{%{epoch}:}|%version-%release:%distepoch`, which is nice.
There is no `distepoch` in `rpm.org`, and in ALT
I see @n3npq has been deleting his posts in the masses again, in this ticket
and elsewhere, right after getting out of the previous ban for doing so. Enough
is enough, @n3npq. This time the ban is until further notice, starting now.
--
You are receiving this because you are subscribed to
> However, from ALT's point of view and ALT's practice, conceptually, there is
> a kind of package dependency which can be satisfied only if another package's
> disttag is equal to the value specified in this dependency.
I think it is off topic. I want to tell about this later, but this
On Sun, 11 Nov 2018, Michael Schroeder wrote:
> Or we keep the disttag out of the EVR comparison, like proposed by @wladmis.
> I believe this is much saner.
Yes, since we don't know about practical uses of comparing the disttags
w.r.t. a linear order (when treating < or > in Requires), it
Or we keep the disttag out of the EVR comparison, like proposed by @wladmis. I
believe this is much saner.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
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
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
> 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
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
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
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
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
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:
> 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
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 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
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
> 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`
@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
(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...
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.
@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:
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.
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.
In other words, 'rpm -qa' should print it and thus 'rpm -q' should understand
it. It should also be a part of the filename, so '/' should not be used
> * Is different disttag for same EVR -- alternatives or ordered number?
Alternatives.
> * I don't like either `.` or `-` because those are widely used everywhere
> so you basically need to change all software which are parsing EVR.
That's true. That is one of reason why I begin the
* Is different disttag for same EVR -- alternatives or ordered number?
* I don't like either `.` or `-` because those are widely used everywhere so
you basically need to change all software which are parsing EVR.
--
You are receiving this because you are subscribed to this thread.
Reply to this
> I think probably the most sane format would be
> `name[-[epoch:]version-[release[.disttag]]][.arch]`.
Thanks for reply, but this format has same disadvantage as that I've proposed,
and unlike "dash" symbol a "dot" symbol is a valid symbol for release, so if it
will be separator for disttag
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.
In addition, I would expect that the DistTag would be part of the filename
format for both source and
34 matches
Mail list logo
