Except for error handling (which will have its own speshul pains),
handling the {E,V,R,D} 4-tuple using the existing PCRE pattern
is largely complete.
Note that this patch affects the python labelCompare() behvaior,
critically important to at least yum.
First two WORKSFORME reports that I hear a
Wuss ;-)
I was hoping for a general solution. Its a hard problem ...
And yes life is short.
73 de Jeff
On Jan 5, 2009, at 2:49 PM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
On Mon, Jan 05, 2009, Jeff Johnson wrote:
> On Jan 5, 2009, at 12:43 PM, Ralf S. Engelschall wrote:
>
>> On Sun, Jan 04, 2009, Jeff Johnson wrote:
>>
>>> On Jan 4, 2009, at 11:07 AM, Ralf S. Engelschall wrote:
>>>
So, I think we have a problem in veryfying GID-0 based files or
dire
On Jan 5, 2009, at 12:43 PM, Ralf S. Engelschall wrote:
Otherwise I'll dig out the flaw.
Ok, I've applied your patch and tested even on the particular
installation (to avoid that my test case is wrong) and unfortunately
the
patch has not caused any difference:
| # /usr/opkg/bin/openpkg r
On Jan 5, 2009, at 12:43 PM, Ralf S. Engelschall wrote:
On Sun, Jan 04, 2009, Jeff Johnson wrote:
On Jan 4, 2009, at 11:07 AM, Ralf S. Engelschall wrote:
So, I think we have a problem in veryfying GID-0 based files or
directories...
I suspect the problem is with "wheel" -> 0 gid mapping,
On Sun, Jan 04, 2009, Jeff Johnson wrote:
> On Jan 4, 2009, at 11:07 AM, Ralf S. Engelschall wrote:
>
>>
>> So, I think we have a problem in veryfying GID-0 based files or
>> directories...
>
> I suspect the problem is with "wheel" -> 0 gid mapping, not with the
> gid 0 verification per-se. Its k
On Jan 5, 2009, at 12:26 PM, Wichmann, Mats D wrote:
converting on checks as you suggest makes sense to me.
And here's the loaded question:
Do I parameterize strcasecmp into the {N,EVRD,F} comparisons?
BTW this whole implementation (I haven't started with N regexes yet) is
headed t
rpm-devel-ow...@rpm5.org wrote:
> On Jan 5, 2009, at 12:05 PM, Wichmann, Mats D wrote:
>>
>> Well, there sure are a lot of current packages out there
>> with uppercase characters in the name
>
> Bah, uppercase, who needs it?!? Use UTF-128 encoding instead!
Heh...
> Otherwise noted. And I'll a
On Jan 5, 2009, at 12:13 PM, Per Øyvind Karlsen wrote:
I still have a concern about compatibility issues though..
Compatibility with __WHAT__ pray tell? You da guy who
is suggesting adding Distepoch: to EVR comparisons everywhere ...
Name the compatibility target, and I'll attempt compatib
On Jan 5, 2009, at 12:05 PM, Wichmann, Mats D wrote:
Well, there sure are a lot of current packages out there
with uppercase characters in the name
Bah, uppercase, who needs it?!? Use UTF-128 encoding instead!
Otherwise noted. And I'll add the ":tolower" (and inverse ":toupper")
header f
2009/1/5 Wichmann, Mats D
> rpm-devel-ow...@rpm5.org wrote:
> > This off-hand comment regarding Mandriva DUDF -> CUDF
> > translation needed by the Mancoosi project reminds me
> > of a design mis-feature in RPM:
> >
> >> - package names: they should match the naming convention we
> >> discussed,
rpm-devel-ow...@rpm5.org wrote:
> This off-hand comment regarding Mandriva DUDF -> CUDF
> translation needed by the Mancoosi project reminds me
> of a design mis-feature in RPM:
>
>> - package names: they should match the naming convention we
>> discussed, i.e., only lowercase characters, numbers,
This off-hand comment regarding Mandriva DUDF -> CUDF
translation needed by the Mancoosi project reminds me
of a design mis-feature in RPM:
> - package names: they should match the naming convention we
discussed,
> i.e., only lowercase characters, numbers, dashes or pluses [1] or
> dots (see s
13 matches
Mail list logo
