Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Handle DistTag (#589)
@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: ___ 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 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: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-438767008___ 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)
@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 there are different branches with no linear order, so I propose follow format for package matching: `name[-[epoch:]version[-release]][:disttag][.arch]`, and may be `%name = %|epoch?{%{epoch}:}|%version-%release:%disttag` to package provides, and `%name-%version-%release:%disttag.%arch.rpm` for package filename. Package format for `dbiFindByLabelArch()` to match: `name[-[epoch:]version[-release]][:disttag][.arch]`. @Conan-Kudo @ignatenkobrain @pmatilai @ffesti are you agree with that? If you are then I will write the code to PR. -- 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-438750965___ 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 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 this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437812728___ 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)
> 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 requires some background, for example, ALT `rpm-build` optimizes subpackages interdependencies (dependecies between packages built from one source package) to strict dependency. Historically, these strict dependecies was like `name = EVR`, but now it is even stricter because it contain a DistTag, as it can be seen in @imz example. But this can be *only* for packages built from one source code. Here is the [code that optimize interdeps](http://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=blob;f=build/interdep.c;h=cab619844724a5b920eac5785cfbea3867c5decb;hb=aa125cd61d1aed7e5d4bab57c236ccfafe7d8e1e#l780). I think this scheme won't be plainly adopted by other distributions but this is a concept you can view on and think about. -- 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-437687475___ 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 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:), which behaves as a partial order, not a linear order.[1] [1]: https://github.com/rpm-software-management/rpm/issues/362#issuecomment-345475643 "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 -- 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-437682327___ 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)
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: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-437668512___ 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 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
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. 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. -- 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-437487005___ 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)
> * 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 discussion. -- 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-435090877___ 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)
* 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 email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#issuecomment-434991739___ 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]`. 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. -- 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-434712563___ 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. 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. -- 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-434550037___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint