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 Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
