On Fri, 10 May 2019 at 22:50, Bruce Dubbs via lfs-dev <
[email protected]> wrote:
> On 5/10/19 3:12 PM, Pierre Labastie via lfs-dev wrote:
> > On 10/05/2019 14:33, Douglas R. Reno via lfs-dev wrote:
> >>
> >> On 5/10/19 2:21 AM, Pierre Labastie via lfs-dev wrote:
> >>> Hi,
> >>>
> >>> I now build the systemd book. I may come back to SysV later, but ATM,
> I want
> >>> to test the BLFS book, and the systemd revision has more thorough
> coverage
> >>> than SysV.
> >>>
> >>> Since i'm new to systemd, I try various commands. That's how I
> realized there
> >>> was a unit (man-db.timer) for running a daily update of the man
> database. So I
> >>> enabled the unit, and after one day, I received an error concerning the
> >>> associated service.
> >>>
> >>> Investigating, it turns out that /usr/bin/find is hardcoded in the
> unit, and
> >>> we have find in /bin...
> >>>
> >>> I wonder how many units have such harcoded paths.
> >>>
> >>> Looking at man-db source, /usr/bin/find is hardcoded also in
> >>> man-db.service.in. So the following sed is needed:
> >>> sed -i 's@/usr/bin/find@/bin/find@' init/systemd/man-db.service.in
> >>>
> >>> Should we add it to the systemd book?
> >>>
> >>> Pierre
> >>
> >> I've got that sed in my sandbox already, but I think it would be good
> to go in
> >> now.
> >>
> >> Please add it :-)
> >>
> >> Not many units are supposed to have hardcoded paths. I don't know if
> this is
> >> related to some upstreams' initiative to push for a merged / and /usr
> (where
> >> /lib and /usr/lib are symlinked, /bin and /usr/bin are symlinked, etc).
> If it
> >> is, it's a very nasty way to do things. Hardcoded paths are rarely a
> requirement.
> >>
> >
> > Hmm, the unit comes from man-db, and was added in last December, to fix
> a bug
> > in Debian. I do not think that debian is pushing for merging / and /usr.
> So,
> > no nasty way, just an oversight, I think...
> >
> > As of whether it is possible to use the system PATH, I cannot tell.
> Somebody
> > with better systemd knowledge than I have should answer: sure it'd be
> better,
> > but only if we can assess that the PATH is set when running the
> service...
> >
> > Another possibility, as suggested, would be to symlink to /usr all the
> > executables we move from /usr/{s,}bin to /{s,}bin (as we do for
> libraries).
>
> Symlinks are a possibility, but I would prefer not doing that if we
> can. Note the that library symlinks are only to the .so files that are
> used by build instructions. These are almost always symlinks anyway.
> The actual libraries are not like libattr.so.1.1.2448 which are not
> symlinked directly. The runtime loader automatically looks in /lib.
>
> I note that our BLFS service files all seem to be using absolute file
> paths so PATH may not be an option.
>
> sed -i /find/s|/usr|| init/systemd/man-db.service.in
>
> Note that this still will work in a merged /usr/bin = /bin system.
>
Maybe I should not have been so terse when I suggested the symlink option
in /usr/bin. To expand my reasoning, I believe that using a sed command on
what is effectively a basic tool is changing the intrinsic nature of that
tool. We do that without producing any documentation of the change other
than within the LFS book build instructions. Yes, I know that we do that
all the time, but, surely, *if* there is a simpler way then that should be
preferred.
And the simpler way is to add a symlink to /usr/bin. This requires no
documentation (other than in the build instructions) as the addition/change
can be seen clearly by any user viewing the filesystem tree.
Richard
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
