This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
RFE: Handle DistTag #589
Comments
|
I think probably the most sane format would be In addition, I would expect that the DistTag would be part of the filename format for both source and binary packages. I can currently force this for binary packages, but I'm not sure how to for source packages. |
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 it will be even worse for parsing. |
|
Alternatives.
That's true. That is one of reason why I begin the discussion. |
…pm-software-management#589) ALT uses DistTag to differ various package builds of the same package NEVR, so dbiFindByLabelArch tries to match the package against name[-[epoch:]version[-release]][/disttag][.arch]. Signed-off-by: Vladimir D. Seleznev <vseleznv@altlinux.org>
|
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 as a separator IMHO. |
Definitely it does not make sense to allow
I'm not sure should Let's decide which format Next, I think it is reasonable to add a new
For now Please, comment. |
|
Let's decide which the format |
|
@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. It's not a normal situation, but quite real when for some reason system upgrade breaks. And there are two different foo-1.0-1 with disttag1 and disttag2. or this way in depend what format rpm will use: PR #594 uses first variant. |
|
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. |
|
(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 uninstall part. That code really has to die, I don't know of any benefits and it's the cause of nasty surprises.) What's the point of an rpmlib() dependency if the disttag is not a part of the dependency resolution? I don't understand the need for it. |
I think this is bad because this would make it impossible to split But this property is already broken because
That's also bad for splitting So unfortunately, the existing separators are bad for this purpose, although that would be nice to re-use one of them for the sake of extensibility. But for their usage to be "extensible", they must have been not allowed in either name or release (or other fields). It's better to forget about 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 Hmmm Perhaps, use |
|
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 you agree ...
Perhaps I don't understand your comment very well.
But I haven't thought about giving parts of NEVR without including the
name as arguments to rpm.
I used the short form `release:disttag` to say that wherever one used to
put the value `release` in his scripts, one might end up putting a string
that actually is `release:disttag` if one has parsed the ouptut of
`rpm -qa` after the proposed changed.
So, that would translate to your specific example (of a script where one
used to put the value `release`):
One used to call:
rpm --query release
If parsing the output of `rpm -qa` after the proposed change, one would
call:
rpm --query release:disttag
I feel that even the first command is strange (`rpm --query release`); I
wouldn't expect it to appear in a useful script. So I don't see a reason
to discuss the second one.
…--
Best regards,
Ivan
|
|
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&v=1.39.2.52
See the 2 (one commented out) definitions of %evr_tuple_match. Both PCRE's as written assume a ':' separator for both Epoch and DistTag.
So, that's an interesting coincidence that independemtly from you I
suggested the same separator/format! I believe this can be viewed as an
indication that it is nice.
One can change the PCRE to use a '.' or '-' or '/' or whatever character one wishes to separate the serial representation of the tuple {E,V,R,D} (or T if twiddle-in-version is desired) that is desired.
So far no one has mentioned the added SuSE inspired twiddle-in-version parsing that is also necessary to handle in dependency strings if DistTag is handled.
I wanted to be concise about the main ideas and not write too much in one
message.
All of the pseudo-regexes mentioned in this issue are incomplete. The PCRE I have pointed out can be used with pcregrep to do try-and-see experimentation with various representations of EVR if DistTag is added.
Thanks!
…--
Best regards,
Ivan
|
|
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 the rest (in an explicit NEVRDA) string is basically
Thanks for writing them out explicitly!
I haven't understood how a command like
rpm --query -- -release
or
rpm --query -- -release:disttag
is relevant for this discussion. Does anyone call `rpm --query` without a
name in the argument?
… The last dash is the separator between V-R, the 2nd to last dash is the separator between N and the rest. None of V or R or D or A may include a dash.
Arch parsing can be handled with a period, followed by key words like "i686" or "x86_64".
What remains is EVRD which must be parsed unambiguously whatever separator characters are used, including unspecified or missing values.
Epoch is a digit string up to the first colon, D (as in the PCRE) is whatever follows the last colon (and colon is a forbidden character in the D string).
The PCRE breaks the EVRD string into substrings assigned to known match indices while also handling missing/unspecified matches.
--
Best regards,
Ivan
|
|
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 me.
(Now that's a talk about the input (arguments) to `rpm --query`, whereas
what I have been talkin before was its *output* format. I was concerned
with extending the output format so that it is not ugly and there is a
little chance to break other scripts that parse it which mustn't
necessarily be broken.)
Adding DistTag just makes the package identifier retrieval "label" more complicated.
So, I'd say that just each of the short forms above must be added a
disttag. Then we'd get the new list of short forms by adding them to the
list above. (As you have said, one might wish to query by just specifying
the disttag, so it's independent from the presence of other values.)
N:D, N-V:D, N-V-R:D, N:D.A, N-E:V:D
We see now that in the input, there would be an ambiguity between `N-V:D`
and `N-E:V`.
To resolve it, we might require to write `N-:V:D`, otherwise let it be
interpreted as `N-E:V`.
Now `N-:V`, `N-:V-R`, `N-:V-R.A` are accepted well already.
(But how to teach the users that they should use a second colon in this
ambiguous case?.. Perhaps, always require the second colon, if they want
to put a disttag in the short form. But that implies also a seconf colon
in the complete form, so that output format should be changed from
`N-[E:]V-R[:D].A` to `N-[E]:V-R[:D].A`, which is a more ugly.)
That's a drawback of choosing colon, which is already used as a separator.
But on the other hand, I don't like the zoo of having all separators look
diferently.
…--
Best regards,
Ivan
|
Even if
I take look at In ALT
I take a look if @imz @n3npq so you are voting for @ignatenkobrain @Conan-Kudo your opinions? |
|
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 satisfy everyone, two variants can be introduced: an epoch-like disttag
and a release-like disttag. Wouldn't it be quite fun? (Then, of course,
I'd put the epoch-like disttag between the name and the epoch in the
format.)
… 2) interoperability when mixtures of packages are installed with/without DistTag.
3) the dbiFindByLabelFoo() reads every package header in Packages (~100Mb), possibly multiple times, trying various matches. The proper way to perform a query like this is to create indices for each field and do a join to minimize the amount of data that must be read. A change to an rpmdb of that magnitude is highly unlikely.
(aside)
There is also the issues of patterns in queries: a join will not solve that problem. RPM5 uses a btree with a prefix key to find candidates to retrieve rather than retrieving every header. But I digress ...
Warning:
My comments here will be deleted within a week: I have negative interest in participating in a DistTag discussion that I have already had, and already implemented. Have fun!
--
Best regards,
Ivan
|
|
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 %{?dist} usage) or is it DEVR (as some might wish)
To satisfy everyone, two variants can be introduced: an epoch-like disttag
and a release-like disttag. Wouldn't it be quite fun? (Then, of course,
I'd put the epoch-like disttag between the name and the epoch in the
format.)
Let's call them SuperEpoch and SubRelease.
Or better: UltraEpoch and InfraRelease to keep one-letter notations possible (UEVRI).
|
|
Or we keep the disttag out of the EVR comparison, like proposed by @wladmis. I believe this is much saner. |
|
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 looks nice
not to implement now something that is not needed.
In ALT, they are unordered alternative values.
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. So,
order is not used, but equality is. Of course, precedence doesn't matter
in this case, but a limited comparison is actually what happens here
conceptually.
Now it is implemented with a "hack": rpmbuild tranlates the disttag into
an additional Provides of a special form. (The corresponding Requires can
also only be added by rpm-build internally, not in the spec-file by a
human.)
Here is an example:
$ rpm -q librpm7 --qf='%{DISTTAG}\n'
sisyphus.214147.300
$ rpm -q librpm7 --provides | tail -2
.sisyphus.214147.300.3.1-librpm7-4.13.0.1-alt4
librpm7 = 4.13.0.1-alt4
$ rpm -q rpm --requires | fgrep librpm
.sisyphus.214147.300.3.1-librpm7-4.13.0.1-alt4
$
If the comparison mechanism used to check the dependencies would be more
flexible, no special "hacks" would be needed, making the code more clear,
probably. It's an information to keep in mind for RPM developers when
thinking about this issue.
(In ALT, there is also another kind of special dependency value
(set:XXXX), which behaves as a partial order, not a linear order.[1]
[1]: #362 (comment) "set-versions"
So, extending the upstream comparison mechanism to more than just a linear
order defined lexicographically on top of the linear orders of individual
components of EVR is something that would make sense for us. Answering
the question about the precedence of a new component in the existing
definition of the order doesn't make much sense for us IMO.)
…--
Best regards,
Ivan
|
I think it is off topic. I want to tell about this later, but this requires some background, for example, ALT |
|
@Conan-Kudo recently I take a brief look at OpenMandriva Lx3. It uses There is no
and may be and Package format for @Conan-Kudo @ignatenkobrain @pmatilai @ffesti are you agree with that? If you are then I will write the code to PR. |
|
FWIW, this may or may not interfere with #2031. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
In ALT we use
disttagas one of build id of package builds (it storesrepository_name.buildtask.subtask), so we need that rpm can handle it.In this message I proposed a format like
name[-[epoch:]version-[release[-disttag]]][.arch], but not everybody likes it 'cause its ambiguity. Lets discuss what the format it should be so we can implement it.The text was updated successfully, but these errors were encountered: