Re: [PATCH 8/9] nfs-utils: don't force use of /sbin as sbindir

[Joshua Lock <joshua.lock@collabora.co.uk>]

On Thu, 2015-09-03 at 12:14 -0500, Mark Hatle wrote:
> On 9/3/15 9:58 AM, Joshua Lock wrote:
> > In a system with a merged /usr /sbin isn't packaged.
> 
> This sounds like an error to me if /sbin doesn't exist at all. It
> should exist
> either as a link to /usr/sbin (or the reverse).. but it should be
> there as lots
> of things expect the directory (or link) to exist.

Sure, it exists in my images but not during packaging. In my testing I
have base_bindir, base_libdir and base_sbindir set to children of /usr
in my distro.conf and a base-files_%.bbappend that creates the
symlinks. Therefore at packaging time the /sbin directory (and symlink)
 doesn't exist.

I admit this commit message is pretty poor and I'll try and remember to
fix it in a v2.

Regards,

Joshua

> (It's also required by the FHS, even though that probably isn't
> enough of a
> concern.)
> 
> > Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
> > ---
> >  meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb | 8
> > ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> > b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> > index 6da8509..42101de 100644
> > --- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> > +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
> > @@ -90,6 +90,14 @@ RDEPENDS_${PN}-stats = "python"
> >  
> >  FILES_${PN} += "${systemd_unitdir}"
> >  
> > +do_configure_prepend() {
> > +        sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g'
> > \
> > +            ${S}/utils/mount/Makefile.am
> > +
> > +        sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g'
> > \
> > +            ${S}/utils/osd_login/Makefile.am
> > +}
> > +
> >  # Make clean needed because the package comes with
> >  # precompiled 64-bit objects that break the build
> >  do_compile_prepend() {
> > 
> 
> So my concern is simply with the commit msg -- not the actual
> implementation.
> What you have above looks correct to me.