On Wednesday 06 April 2016, Karel Zak wrote: > On Wed, Apr 06, 2016 at 12:51:06PM +0200, Ruediger Meier wrote: > > configure --disable-uuidd disabled both the build of uuidd and also > > disabled uuidd support of libuuid. > > Yes. > > > Now we build libuuid always with uuidd support. > > Not sure if I follow... we always build uuidd and uuidd support > within libuuid except situation you specify --disable-uuidd. > > > +++ b/libuuid/src/gen_uuid.c > > @@ -329,7 +329,7 @@ try_again: > > return ret; > > } > > > > -#if defined(HAVE_UUIDD) && defined(HAVE_SYS_UN_H) > > +#ifdef HAVE_SYS_UN_H > > So you want uuidd stuff in libuuid although --disable-uuidd has been > specified? Why? Same reason like for the 2nd patch. openSUSE packagers want do disable uuidd in the "first stage build" because of systemd dependency. But they still want full functionality in libbuuid. They build uuidd later in "stage 2". Personally I don't like this openSUSE packaging style. But I see the general problem that util-linux as a bunch of low-level tools has already too much dependencies (systemd, python). This can be annoying for certain ways how distros do their bootstrapping. > The --disable-uuidd is (or should be) pretty common for desktop-only > distros. I thought why shouldn't libbuuid always try the uuidd socket? Like glibc always tries nscd, regardless if that evil beast is running or not. Does it matter that nscd or uuidd was not built? Maybe one wants to use another implementations of these daemons. > IMHO the current behaviour is correct. What about adding --enable-libuuid-force-uuidd without changing any current behavior? cu, Rudi -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
