On 07 Jul 2015 00:05, Bruce Dubbs wrote: > Mike Frysinger wrote: > > On 06 Jul 2015 13:58, Bruce Dubbs wrote: > >> Mike Frysinger wrote: > >>> On 03 Jul 2015 14:58, Stef Walter wrote: > >>> #ifdef AGETTY_RELOAD > >>>> # include <sys/inotify.h> > >>>> +# include <linux/netlink.h> > >>>> +# include <linux/rtnetlink.h> > >>> > >>> why not use libmnl instead ? > >>> http://netfilter.org/projects/libmnl > >> > >> That would not work for the LinuxFromScratch project. At the time > >> util-linux is built, libmnl is not available. > > > > then update the LFS insns to include libmnl, or build util-linux with the > > reload option disabled. i don't see how LFS's decisions are relevant here. > > Yes, we can do either, but it seems like a lot of overhead to add a new > package for 95 lines of code that are already written. > > We already manage about 1000 packages and are volunteers. Many of my > users would call adding a new library for one minor function bloat. > None of the packages we support now use that library although that could > change in the future if others start to use it. > > Yes, our decisions are only a minor input to upstream packages, but > there may be others that have similar concerns that don't monitor this list. the whole point of libmnl is to provide a clean userspace library API that is completely standalone & minimal (it's in the name) so people don't have to learn the low level netlink APIs nor have to include linux/ headers directly (which often lead to clashes with the C libraries). libmnl itself is <20KiB, so i don't buy the bloat argument. even then, if we do use libmnl in util-linux, it'd have configure checks so that if the system doesn't have it, it'd be disabled automatically. i'm surprised you're complaining about libmnl but not the other large external libs that util-linux utilizes. another point of information: the latest iproute2 now requires libmnl, so that ship has already sailed. -mike
Attachment:
signature.asc
Description: Digital signature
