> Why not?
> The only justification I can infer from your message is via
> your mention of "cost". Are you concerned about run-time cost,
> disk space cost, maintenance cost or some other?
Maintenance and, secondarily, RAM cost.
> However, I would welcome Bruno's proposed sets and mappings.
> Just because they're initially added to gnulib does not mean
> they can never become independent libraries.
Maybe we need a documented way of making shared gnulib subsets like
Bruno's libunistring.
> Think of gnulib as an incubator.
> Some parts may eventually migrate out to become their own
> separate libraries once they are mature and if they are used
> widely enough.
I see your point, but that's the opposite of the usual argument that
gnulib can be static because it's mostly made of mature and stable
components. The other part of the argument is that gnulib is very
small on GNU systems, but that only applies to the POSIX wrapper part
of gnulib (which is the most useful part, especially for header files,
but probably does not even constitute the majority of it).
>> In fact, glib or libnih probably provide all that you need already,
>> and they're always loaded on a modern Linux system so their cost is
>> effectively zero. (Then, getting stuff into glib is a royal pain in
>> the ass).
>
> Not everyone can depend on "glib" being installed.
> Are you seriously suggesting that one of those libraries become
> a prerequisite of fundamental packages like find, tar and coreutils?
libnih is used by upstart (which is /sbin/init), so that would
actually make some sense. It is installed in /lib under Linux
systems:
libnih.so.1 => /lib64/libnih.so.1 (0x0000003cb3000000)
The key point would be to make such a library small enough that it
could be distributed in the coreutils (etc.) tarballs, and linked
statically for non-Linux systems.
Paolo
post scriptum for the GNU/Linux police: I'm talking explicitly about
the non-GNU bits of GNU/Linux, i.e. those that are not in GNU/Hurd or
GNU/kFreeBSD. :)
