On Mon, Mar 14, 2016 at 02:43:40AM +0100, Ruediger Meier wrote: > On Tuesday 08 March 2016, Isaac Dunham wrote: > > On Tue, Mar 08, 2016 at 12:11:50AM +0100, Ruediger Meier wrote: > > > From: Ruediger Meier <ruediger.meier@xxxxxxxxxxx> > > > > > > This is github pull request #299 > > > https://github.com/karelzak/util-linux/pull/299 > > > > > > Again some arbitrary BSD, OSX and musl related fixes and clean-up > > > > <snip> > > > > > For OSX one should additionally disable all utmp.h related > > > programs. > > > > FYI: > > With musl, utmpx is stubbed out and utmp is wrappers for utmpx, so > > users should disable utmp(x)-related programs and code. > > > (The point is to let things build, but not use utmp because the > > maintainer considers it a fundamentally flawed idea.) > > > > Additionally, systemd is working on allowing disabling of utmp(x). > > Will there be another interface to be used by last(1)? > > > This seems to imply that --disable-utmp/--disable-utmpx options would > > be helpful. > > Do you mean --without-utmp to build our progs without utmp or really > disabling the build of all progs which are using utmp right now? > > Actually I thought the next step could be to remove utmp and use utmpx > only because it's POSIX and more portable. See commit d00c10ed. > > There are still two files to be fixed > login-utils/last.c > login-utils/su-common.c Well, programs like login(1) and su(1) use btmp to log failed login attempts, it should be enough to check if _PATH_BTMP exists, otherwise ignore the file. If we want to use --without-utmp then only for portability (libc does not provide relevant headers). I guess we want to support work with (archived) utmp files, so programs like utmpdump makes sense everywhere (if possible). The last(1) or lslogins(1) have to be smart enough to ignore missing files by default. So again, --without-utmp should be about portability only. Karel -- Karel Zak <kzak@xxxxxxxxxx> http://karelzak.blogspot.com -- 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
