Re: [PATCH] dhcp: Update to 4.2.3-P2

[Phil Blundell <philb@gnu.org>]

On Wed, 2012-02-08 at 14:30 -0200, Otavio Salvador wrote:
> On Wed, Feb 8, 2012 at 14:10, Phil Blundell <philb@gnu.org> wrote:
>         This isn't just a straightforward update, you seem to be
>         moving dhclient
>         from ${base_sbindir} to ${sbindir}.  If that's a good thing
>         (which
>         doesn't seem totally obvious to me) then it ought at least to
>         be
>         mentioned in the commit message.
>         
> 
> He is doing that because it links against libcrypt that is at
> ${libdir}. But it clearly needs to be in another commit or, at least,
> explicit in the changlog.

Yeah, I guessed it was probably something like that.  But this seems
like a bad solution since anybody who has /usr separate probably does
want dhclient during bootup.  In particular, if you have /usr on NFS
then you might be hosed if dhclient is in /usr/bin.

It seems like the right way to fix this is one of:

a) move libcrypto to ${base_libdir}, or
b) stop dhclient from linking against libcrypto, or
c) make it link against the static rather than shared library

Do we know why dhclient has grown this dependency on libcrypto in the
first place?  Or, as an alternative data point, is there a particular
reason why this upgrade is required (i.e. could we just stick with the
old version)?

But, the main point I was trying to make was that the checkin message
did not adequately describe what the patch was doing.  I think the
quality of patches that are being applied to oe-core is, for the most
part, pretty good nowadays but there still do seem to be quite a few
with poor/inaccurate checkin messages and this is an area where it seems
like it should be possible to do better with relatively little effort.  

For example, looking at the git log for the last week, there are at
least 3 commits which don't have the recipe name at the start of the
subject line.  Although this sounds like a trivial thing it is actually
quite annoying if you're trying to scan the git logs to see what changes
have been applied to a recipe or set of recipes.  Similarly, if the
commit message can't be relied upon to accurately describe what has been
changed, you end up having to read all the diffs for every change which
is quite a tedious business.

p.