Re: EVR issues: set:versions, epoch-as-string, now twiddle-in-version
On Apr 23, 2012, at 10:32 AM, Jeff Johnson wrote: I should point out that writing the attached message (and sending from the wrong e-mail address) has instantly led to a different -- and perhaps more natural -- syntax like Requires: set(libfoo.so.1) = whatever After a month of quietly muddling, I like this namespace like syntax better because it doesn't lead to magic tokens like set: in the EVR string and is more consistent with existing namespaces in RPM dependencies. I'll leave the existing set: prefix as is until I implement the set(…) syntax. for set:versions, and for the generalization (for writing strict regression tests, its mostly useless in packaging because there is no mapping that specifies how the mixed DEB - RPM version comparison might be done naturally) Requires: deb(foo) = E:V-R Requires: rpm(foo) = E:V-R (aside) And this is a rather easy/natural extension to choose between alternative version comparisons (at least for development/testing). OTOH, its mostly useless for dependency assertion evaluation because there is no clearly identified mixed comparison when Provides: deb(foo) = E:V-R Requires: rpm(foo) = E:V-R I suppose I can attempt a resolution like this Prefer an explicit comparison in the Provides: if there is a conflict. Prefer an explicit comparison over an implicit/default comparison Use the default comparison if no explicit comparison hint is present. The precedent for foo(bar) name spacing in RPM dependencies with the above syntax is already widely deployed although entirely de facto. Sure would be nice _NOT_ to have to consider Have it your own way! competing syntaxes like Requires: libfoo.so.1 = set:whatever and Requires: set(libfoo.so.1) = whatever (and I'll ignore the gawdafulness of existing multilib dependencies like Requires: libfoo.ao.1()(64bit) coming along rapidly as a Newer! Better! Bestest! ABI standard now that there is support in kernel = 3.2. *shrug* Its all implementable, just not very KISS when aesthetic/innate opinions get involved. OK, I'm in the last stages of adding twiddle-in-version so its time to consider other changes: 1) Epoch as a string? The only lossage here is when digit strings differ in length (and strcmp isn't identical to arithmetic comparison). Alternatively, should Epoch's be forced to a [0-9]+ digit string? 2) Is there a need for twiddle-in-epoch(assuming a string) twiddle-in-release twiddle-in-distepoch There are/were several ways to implement twiddle-in-version; so far I've chosen to do only twiddle-in-version because that involved little more than rewriting some regex patterns. OTOH, handling twiddle-in-version as a special case of a more general string comparison (aka rpmvercmp) is at least as much of a problem as just permitting the full generalization. 3) revisiting dependency ranges with syntax like this Provides: foo = [1.2-3|4.5-6) which would match only Requires in the range, including 1.2-3 because of the '[' and excluding 4.5-6 because of the ')' with the usual mathematical conventions (in the US). The problematic character would be choosing a separator (I used '|' in the example): almost all the usual characters have pre-existing usages, but perhaps something could still be twitched together. 73 de Jeff __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: EVR issues: set:versions, epoch-as-string, now twiddle-in-version
On Wed, May 30, 2012 at 2:56 PM, Jeff Johnson n3...@me.com wrote: OK, I'm in the last stages of adding twiddle-in-version so its time to consider other changes: 1) Epoch as a string? The only lossage here is when digit strings differ in length (and strcmp isn't identical to arithmetic comparison). Alternatively, should Epoch's be forced to a [0-9]+ digit string? I don't see the usefulness of Epoch as a string. I would rather have it just integers, higher takes precedence. Much less mind boggling. 2) Is there a need for twiddle-in-epoch(assuming a string) twiddle-in-release twiddle-in-distepoch There are/were several ways to implement twiddle-in-version; so far I've chosen to do only twiddle-in-version because that involved little more than rewriting some regex patterns. OTOH, handling twiddle-in-version as a special case of a more general string comparison (aka rpmvercmp) is at least as much of a problem as just permitting the full generalization. 3) revisiting dependency ranges with syntax like this Provides: foo = [1.2-3|4.5-6) which would match only Requires in the range, including 1.2-3 because of the '[' and excluding 4.5-6 because of the ')' with the usual mathematical conventions (in the US). The problematic character would be choosing a separator (I used '|' in the example): almost all the usual characters have pre-existing usages, but perhaps something could still be twitched together. Can you explain twiddle-in-* to me? I'm slightly confused. (Shows how much I haven't kept up with anything within like the past... year .) -- later daze. :: Robert Xu :: protocol.by/rxu __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: EVR issues: set:versions, epoch-as-string, now twiddle-in-version
On May 30, 2012, at 3:09 PM, Robert Xu wrote: On Wed, May 30, 2012 at 2:56 PM, Jeff Johnson n3...@me.com wrote: OK, I'm in the last stages of adding twiddle-in-version so its time to consider other changes: 1) Epoch as a string? The only lossage here is when digit strings differ in length (and strcmp isn't identical to arithmetic comparison). Alternatively, should Epoch's be forced to a [0-9]+ digit string? I don't see the usefulness of Epoch as a string. I would rather have it just integers, higher takes precedence. Much less mind boggling. And Epoch: as integer requires special casing of an integer data type everywhere. strings are easier for the implementation and for metadata data types. I'd rather have a means to eliminate Epoch: … Epoch: is easily dropped out everywhere by adding this to RPM configuration %evr_tuple_order VR and all epochs will be parsed in dependency strings and ignored. 2) Is there a need for twiddle-in-epoch(assuming a string) twiddle-in-release twiddle-in-distepoch There are/were several ways to implement twiddle-in-version; so far I've chosen to do only twiddle-in-version because that involved little more than rewriting some regex patterns. OTOH, handling twiddle-in-version as a special case of a more general string comparison (aka rpmvercmp) is at least as much of a problem as just permitting the full generalization. 3) revisiting dependency ranges with syntax like this Provides: foo = [1.2-3|4.5-6) which would match only Requires in the range, including 1.2-3 because of the '[' and excluding 4.5-6 because of the ')' with the usual mathematical conventions (in the US). The problematic character would be choosing a separator (I used '|' in the example): almost all the usual characters have pre-existing usages, but perhaps something could still be twitched together. Can you explain twiddle-in-* to me? I'm slightly confused. Go read the Debian documentation or ask SuSE where the need for twiddle-in-version is. Perhaps the most complete description of already implemented alternatives @rpm5.org is here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=256 I am forced to compatibility (with dpkg in Yocto) and feature parity (released in rpm-4.10.0) on an unnecessary (imho) implementation complexity adding twiddle-in-version @rpm5.org. The original RFE (from SuSE) is here http://www.rpm.org/ticket/56 (Shows how much I haven't kept up with anything within like the past... year .) The twiddle-in-version RFE started in 2008, was proposed in the OpenSUSE RPM Summit ROADMAP on September 18th, 2009, and has just been released. That SHOULD tell you a lot about the urgency and necessity of twiddle-in-version in RPM. 73 de Jeff
Re: EVR issues: set:versions, epoch-as-string, now twiddle-in-version
On Mon, Apr 23, 2012 at 6:32 PM, Jeff Johnson n3npq@gmail.com wrote: I should point out that writing the attached message (and sending from the wrong e-mail address) has instantly led to a different -- and perhaps more natural -- syntax like Requires: set(libfoo.so.1) = whatever Hello, Set-versions are just that - versions. One must arguably think of them in terms of VERSIONS. If you need a library, it is a legitimate question to ask which version you need. If you think you need the version at least 1.0, there's a good question: why the heck you think you need the version at least 1.0 (and whether 2.0 would still fit). With set-versions, things get straightforward: you need at least a version which provides foo, bar, baz API symbols - that's much better a description of a library than a god-damn arbitrary number. There are some philosophical implications of introducing set-versions, in particular, whether it can be extended to describe prototypes and calling conventions (e.g. the number of arguments which must be passed to a function). This is why I might seem reluctant to participate in discussions. I'm thinking! (And perhaps I'm arrogant.) for set:versions, and for the generalization (for writing strict regression tests, its mostly useless in packaging because there is no mapping that specifies how the mixed DEB - RPM version comparison might be done naturally) Requires: deb(foo) = E:V-R Requires: rpm(foo) = E:V-R The precedent for foo(bar) name spacing in RPM dependencies with the above syntax is already widely deployed although entirely de facto. Sure would be nice _NOT_ to have to consider Have it your own way! competing syntaxes like Requires: libfoo.so.1 = set:whatever and Requires: set(libfoo.so.1) = whatever __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: EVR issues: set:versions, epoch-as-string, now twiddle-in-version
On May 30, 2012, at 9:46 PM, Alexey Tourbin alexey.tour...@gmail.com wrote: On Mon, Apr 23, 2012 at 6:32 PM, Jeff Johnson n3npq@gmail.com wrote: I should point out that writing the attached message (and sending from the wrong e-mail address) has instantly led to a different -- and perhaps more natural -- syntax like Requires: set(libfoo.so.1) = whatever Hello, Set-versions are just that - versions. One must arguably think of them in terms of VERSIONS. If you need a library, it is a legitimate question to ask which version you need. If you think you need the version at least 1.0, there's a good question: why the heck you think you need the version at least 1.0 (and whether 2.0 would still fit). With set-versions, things get straightforward: you need at least a version which provides foo, bar, baz API symbols - that's much better a description of a library than a god-damn arbitrary number. Yes VERSIONS. The issue for RPM is how to represent/attach a different VERSION comparison. A prefix marker with set: is mostly sane (until there are multiple meanings for ':' and '~' and '-' separators parsing the serialized VERSION representation which is increasingly the state of affairs @rpm5.org). So its perhaps a more natural syntax and a cleaner representation to use the existing name spacing convention with the form Requires: set(bar) = VERSION to distinguish in a namespace the VERSION that needs a different comparison method attached. But these are mostly details (until one has to write the parsing regex and watch the combinatorial explosion of possibilities with optional fields). But I'm biased at the moment, having just today added twiddle-in-version ... There are some philosophical implications of introducing set-versions, in particular, whether it can be extended to describe prototypes and calling conventions (e.g. the number of arguments which must be passed to a function). This is why I might seem reluctant to participate in discussions. I'm thinking! (And perhaps I'm arrogant.) Thinking is good and arrogance matters little (to me ;-): set:versions is the right thing to do, collapsing multiple redundant just in case assertions into a single dependency representation. hth 73 de jeff for set:versions, and for the generalization (for writing strict regression tests, its mostly useless in packaging because there is no mapping that specifies how the mixed DEB - RPM version comparison might be done naturally) Requires: deb(foo) = E:V-R Requires: rpm(foo) = E:V-R The precedent for foo(bar) name spacing in RPM dependencies with the above syntax is already widely deployed although entirely de facto. Sure would be nice _NOT_ to have to consider Have it your own way! competing syntaxes like Requires: libfoo.so.1 = set:whatever and Requires: set(libfoo.so.1) = whatever __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: EVR issues: set:versions, epoch-as-string, now twiddle-in-version
On Thu, May 31, 2012 at 6:51 AM, Jeffrey Johnson n3...@me.com wrote: We are in violent agreement here over a minor issue of implementation/representation. By the way, actual problems that will arise are rarely what you expect them to be. In 2010, I was naive and I thought that char bitv[] was a pretty good representation of bit sequence (which can be still seen in set.c). It then took many days to devise a sophisticated decoding routine which avoids bitv[] altogether and makes things smooth. So, in a violent agreement, don't take things for granted. :-) The mixed code case is interesting: what happens if a set:version encoding contains the literal string 0:V-R I can't understand you question. A version is either a set-version, or not a set-version. If a version is a set-version, it has to be prefixed by set:. Regular RPM versions cannot be prefixed by set:, because set cannot be decoded as a valid serial number, which has to be an integer. There might be some implementation sloppiness out there, but in principle, I believe the encoding scheme is sane, and makes sense. Now the question is, what if a set-version cannot be decoded? But that can be perplexed by a question, what if a regular rpm version cannot be decoded? Or can you decode any junk as a valid RPM version? and a match is attempted against a traditional dependency like Provides: foo = 0:V-R If the literal string in the Provides: is encoded on the fly, will setcmp(…) match or not? __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: EVR issues: set:versions, epoch-as-string, now twiddle-in-version
On May 30, 2012, at 11:24 PM, Alexey Tourbin alexey.tour...@gmail.com wrote: On Thu, May 31, 2012 at 6:51 AM, Jeffrey Johnson n3...@me.com wrote: We are in violent agreement here over a minor issue of implementation/representation. By the way, actual problems that will arise are rarely what you expect them to be. In 2010, I was naive and I thought that char bitv[] was a pretty good representation of bit sequence (which can be still seen in set.c). It then took many days to devise a sophisticated decoding routine which avoids bitv[] altogether and makes things smooth. So, in a violent agreement, don't take things for granted. :-) In 2001, I thought that typedef'd enum's were the best implementation for named bit fields because the names were displayed in gdb backtraces. There is some speshul painfulness not only from the typedef's in both C/C++ but also from the inability to extend the no. of bits beyond whatever and int contains. But these are implementation issues which I choose to call minor ;-) The mixed code case is interesting: what happens if a set:version encoding contains the literal string 0:V-R I can't understand you question. A version is either a set-version, or not a set-version. If a version is a set-version, it has to be prefixed by set:. Regular RPM versions cannot be prefixed by set:, because set cannot be decoded as a valid serial number, which has to be an integer. There might be some implementation sloppiness out there, but in principle, I believe the encoding scheme is sane, and makes sense. Now the question is, what if a set-version cannot be decoded? But that can be perplexed by a question, what if a regular rpm version cannot be decoded? Or can you decode any junk as a valid RPM version? I'm trying to understand rpmsetcmp() as a black box independent of all the gory implementation details of ELF symbols, base62 encoding, and RPM dependencies. I believe that set:versions are much like Bloom filters: 1) strings can be added to a set in any order 2) the comparison operation implied by Requires: foo = set:…. is identical to contained in or is subset of Is that the case? 73 de Jeff and a match is attempted against a traditional dependency like Provides: foo = 0:V-R If the literal string in the Provides: is encoded on the fly, will setcmp(…) match or not? __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
