[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian patches

From: Jim Meyering
Subject: Re: Debian patches
Date: Fri, 05 Mar 2010 15:41:18 +0100

Reuben Thomas wrote:
> 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.

On some systems, libpcre is under /usr, and on Debian it used to be
(long ago), to the chagrin of all of us who ended up having unbootable
systems after a grep upgrade that made grep link to it.

It must be a run-time linkage, since grep must be able to run
when only /bin is mounted, and /usr/lib is not yet available.
It's ok if pcre-related code fails to run in early boot-related
scripts, but grep must not link to any library in /usr/...

> 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.

Sounds good to me.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]