Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437645237___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437645122___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 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!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437644351___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
> 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 don't like it, but it is an option for that case. > 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 %evr_tuple_match. Both PCRE's as > written assume a ':' separator for both Epoch and DistTag. I take look at %pattern_Disttag^[A-Za-z0-9]+$ In ALT `.` is a valid symbol for `DistTag` and widely used for now. > Perhaps, use `:` again? Something like: > `name-[epoch:]version-release[:disttag].arch` without changing the trailing > `.arch` to be compatible with those consumers who parse this and expect the > tail after the last dot to be arch. (They might get the release as > `release:disttag` after parsing, but as long as this is invalid as a release > for rpm, that's OK, because they would fail if they tried to use this string > as a release, and the failure would indicate that they need an upgrade of > their code.) I take a look if `:` is good separator but it is valid symbol for `release` for ALT, so I decided to not using it when I was preparing the PR. But it seems to be invalid for others and it seems that no package in ALT actually use `:` in `release`. @imz @n3npq so you are voting for `:`? @ignatenkobrain @Conan-Kudo your opinions? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437644011___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 definite advantages IMHO trying to use a simple foo:bar:baz scheme rather than adding all sorts of ornamentation and forbidding characters in intervening fields. YMMV, have at, if the PCRE is read from configuration and used for parsing (as in RPM5), all the separators can (at least in principle) be changed to taste without changing code. Another possible way to fix the error is to limit DistTag to a known reserved key word set or form and changing the PCRE. The key issue is having a EVRD parser that never errors: unrolling the stack from EVRD parsing just isn't going to happen, and rpm has too much state to manage to just exit. In most cases the user will just receive a weird error and exit with a message if the ambiguity you point out is ever encountered. Supplying more fields also avoids the ambiguity. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437643494___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437642074___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437639456___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 missing/unspecified values are interpreted as matching any value. But I can definitely foresee a need to query all packages with a given DistTag which would become Rpm --query -- --:D The ugly syntax can be hidden in various ways: what is important is that the underlying parser is fed a well formed unambiguous query string which can be matched against existing NEVRDA package identifiers with possible missing values to retrieve a set of packages of interest. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437639173___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437638738___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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
>
> 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
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437638531___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
@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 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437638429___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 %evr_tuple_match. Both PCRE's as
written assume a ':' separator for both Epoch and DistTag. 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.
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437637165___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437636770___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437635866___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
> 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` correctly without knowing the version of rpm. (Remember that `.` is allowed in release.) But this property is already broken because `rpm -qa` used to print `name-version-release`, then changed to `name-version-release.arch` > ...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. That's also bad for splitting `name-version-release-disttag.arch` correctly (for similar reasons): `-` is allowed in name, so finding the release and version is a matter of counting the dashes from the end. 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 `.` and `-`, and introduce something that would allow to split confidently. 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. Hmmm Perhaps, use `:` again? Something like: `name-[epoch:]version-release[:disttag].arch` without changing the trailing `.arch` to be compatible with those consumers who parse this and expect the tail after the last dot to be arch. (They might get the release as `release:disttag` after parsing, but as long as this is invalid as a release for rpm, that's OK, because they would fail if they tried to use this string as a release, and the failure would indicate that they need an upgrade of their code.) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437635342___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
@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 --install/-i, which is most definitely used by kernels, and promises never to erase any file or package. Kernel installs are special: the root problem is semantic confusion between "install" and "upgrade" as separate modes. The distinction (like --addsign/--resign) is too subtle for most users and should be coalesced by making --install and --update behave identically (pleasing most users) and devising a means to preserve kernel install behavior. There is no point to a package specified DistTag related tracking dependency imho. And there is little reason (other than the reasoning I supplied above) for DistTag to be drilled throughout package dependencies. Similarly (but too late to change), there was little reason to drill Arch into package dependencies (coloring would have sufficed), but WYSIWYG and the RFE to add DistTag to file naming, and within version comparison, is entirely predictable. Been there, done that, wrto DistTag 9y ago ... *yawn* -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437634249___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
(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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437626406___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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 GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437621031___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
> @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. `rpm` should be able to handle this and there should be a way to tell what build we what to erase. For example: rpm -e foo-1.0-1/disttag1 or this way in depend what format rpm will use: rpm -e foo@disttag1-1.0-1 PR #594 uses first variant. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437619575___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
@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: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437616652___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
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: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437612833___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle disttag (#589)
> 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. Meanwhile dependencies has `EVR` on the set of which comparison operations are defined, which cannot be defined for `DistTag`. > 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. I'm not sure should `DistTag` be or not a part of the filename, it seems to be safer if it wouldn't, but if it would then the filename will be more descriptive. Let's decide which format `dbiFindByLabelArch()` should match. I propose `N[-V[-R]][/D][.A]`, the reasoning is that this collision proofed against any other fields `name`, `version`, `release` and `arch`, it's compatible with the current format, it's easy to parse and requires a little changes in the source code. @ignatenkobrain proposes `N@D:E-V-R.A`, but this seems a bit strange, I would change this to `N[@D][-[E:]V[-R]][.A]` that is fine to me, compatible with current format and allow plainly put the `DistTag` value to the filename as it is in the full format record. @Conan-Kudo is for `N[-[E:]V[-R][.D]][.A]` or `N[-[E:]V[-R][-D]][.A]` but I don't like neither of these cause its issues. Next, I think it is reasonable to add a new `rpmlib feature`. `rpm` that can handle the new format should provides this feature, and a package that was built with non-empty `DistTag` should requires this feature. Of course we cannot backdate this requirement for existing packages with non-empty `DistTag`, but this can add this requirement for new packages. @Conan-Kudo actually I don't like the name `rpmlib(DistTagInVersionComparison)` cause the feature is not about "version comparison", it's about "build matching". > In other words, 'rpm -qa' should print it For now `rpm -qa` prints `NVRA` but I also think that printring `NEVRA+DistTag` in the format would be more informative, but I also cannot be sure that this change does not break something. Please, comment. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437612820___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
