On Thu, May 31, 2012 at 9:03 AM, Jeffrey Johnson <n3...@me.com> wrote: >>> 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?
To me, a set-version is just a VERSION. I can't stress that enough. When you need a library, it is a legitimate question to ask which version you need. If you answer that you need at least version 1.0, a conventional version, you must be kidding. Because there is no connection between what you actually need and a god-damn number. So a plausible answer must be "Well, we need at least a version which provides <foo, bar, baz> symbols which we need to use". Let's take this approach to the extreme, and say that the VERSION which we need is simply the one which provides at least <foo, bar, baz> symbols. To me, this is much better an approach to library versioning, and possibly the only viable approach. How else can you express your expectations about a library? Suppose someone is talking to you at a conference, and says "Mr. Johnson, we are very proud, blah-blah-blah, because blah-blah-blah". What you want to tell them is basically "Go out, folks, it works". Now, with set-versions, things really work. :-) Back to implementation, 1) set-strings should be considered opaque, static, and unmodifiable. Once they are formed, there is no useful way to alter them. They express an idea of a VERSION in a manner which cannot be easily comprehended, but that's not a problem (or otherwise there is perplexing questions of what regular rpm versions must mean, and whether any piece of junk can be decoded as a regular rpm version). 2) They must compare as sets, in terms of elements unique to the first set, common elements, and elements unique to the second set. The implementation does not quite much yet, because it already tries to mimic regular versions. Regular versions are linear order. Set-versions are partial order. You cannot always compare set-versions in terms of "greater or equal" (but when you can, it's important). ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
