Re: Debian patches

[Reuben Thomas]

2010/3/5 Paolo Bonzini <address@hidden>:
> On 03/05/2010 11:28 AM, Reuben Thomas wrote:
>>
>> 2010/3/5 Paolo Bonzini<address@hidden>:
>>>
>>> 03-dlopen-pcre.patch
>>>        Ialso not appropriate for upstream (not in its current shape
>>>        anyway since it should at least use ltdl and not hardcode the
>>>        soname).
>>
>> This is originally from me; it's also in the patch tracker on
>> Savannah, #7017. Your answer above implicitly addresses my question,
>> which is which dynamic loading mechanism I should use. If you'd repeat
>> that comment on the patch tracker (if using ltdl is indeed the
>> answer), then I could move forward...
>
> Usually when building from source either you have a dependency or not;
> run-time dependencies in something as fundamental as grep seem strange.

The reason for it in Debian is that grep is in /bin whereas libpcre is
in /usr/lib. In Fedora, I believe that libpcre is in /lib. I believe
that grep's location, at least, is standardised, so there is some
system-neutral sense to this.

I do not have a strong opinion on this (personally, of course, it's
easier if I don't have to update the patch to be system-neutral!). If
you don't think it's appropriate for upstream, then you should remove
it from the TODO list at

http://www.gnu.org/software/grep/devel.html

By the way, I see the list here is rather more complete than the TODO
file in grep, which itself looks as though it might be capable of some
updating. If I were to merge the two and post it as a patch to grep's
TODO, would the maintainers care to prune it? Maybe the web page could
then be made simply to point to the version in Savannah.

While we are on the subject, I have two other patches, one to improve
the man page in its discussion of PCRE (#7016), and another to provide
transparent decompression (which may be a bit much for grep 2.6, but
again, it addresses a TODO list item, and it's at patch #6107). If
you're interested in either of those I can bring them up to date with
git master (they've both fallen behind, as has #7017).

I notice while scanning the patch tracker that it is probably worth
pruning too, and that there are two other sets of distributor patches
mentioned there, from Apple and RedHat.

-- 
http://rrt.sc3d.org