| >Does it really make a difference whether it's called libsystemd or something else? Probably not. But when I think of something named "libsystemd" I think of a library to interact with systemd, not a collection of random hashmap and B-tree implementations. > If you're talking about the other functionality that's private and unstable Why would I talk about factoring out private and unstable code into a shared library. But if udev is depending on that private and unstable code I do have a lot more sympathy for the packagers who are wary of the merger. It's kind of disengenuois to claim that they're totally separate projects, and can reliably be deployed separately when they both depend on some private special sauce. Even if the sauce is open sourced. > Also I'm not sure if you're joking with that name Half a joke and half trying to avoid the "I hate the name" problem. You have clarified a little bit of what that library is actually doing. And why it seems to make sense to have udev pick up the dependency. Thank you. |