Link to libglib, use it in one place to start

[cgwalters]

libglib is a hard requirement of other projects on the host, such
as libostree. Let's make use of it, since it has a lot of useful
functionality for C programs.

Specifically, it aborts on OOM by default (because in practice anything that
isn't the kernel/pid 1 isn't going to be able to continue), so we can just use
g_strdup().

(Note that it's required nowadays that g_malloc() = malloc(), so it's
OK that we're passing this to free().)

[rhatdan]

LGTM
If we need to reopen this for further fixes we can take advantage of it.

[rhvgoyal]

So what are we gaining by using g_strdup() instead of strdup(). IOW, why should we switch to using libglib. Other projects are using it, hence we should use it, feels like a weak argument.

[rhatdan]

Well we could have used chomp instead of implementing our own whitespace stripper.

[cgwalters]

That's just the start to avoid conflicting with other outstanding work. GPtrArray replaces things like free_cptr_array(), g_strsplit() is way better than strtok(), etc.

[rhvgoyal]

My point is, are there big gains to be had by switching library. And I am not able to see that. Little bit change here and there does not really justify putting that effort and test it again. This time could well be spent somewhere else.

If there are no big gains to be had, why to just create more work and testing for ourselves.

[rhvgoyal]

We are not anticipating lot of development in oci-umount. And at some point of time it might just disappear because kernel will be new enough and removing directory will remove mount points from other mount namespaces. So really don't see a point in switching library now for a project which does not anticipate lot of development and does not have a long life.