2010/3/5 Paolo Bonzini <[email protected]>: > On 03/05/2010 11:28 AM, Reuben Thomas wrote: >> >> 2010/3/5 Paolo Bonzini<[email protected]>: >>> >>> 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
