Duplicate hashtab code in libsepol vs. policycoreutils/newrole?

Duplicate hashtab code in libsepol vs. policycoreutils/newrole?

[Ondrej Mosnacek]

Hello everyone,

I noticed that there is a duplicate hashtab.[hc] code from libsepol in
policycoreutils/newrole. Can this be deduplicated somehow? I can think
of three options:
1. link to libsepol (a bit unsafe, since hashtab symbols are not
versioned, but other programs already use non-versioned symbols form
libsepol anyway...),
2. statically link with libsepol's hashtab.o (libsepol code would be
needed in ../../libsepol to build newrole)
3. turn the newrole files into symlinks that link to libsepol ones
(similar issue as above, the symlinks would have to be substituted for
actual files when creating release archive).

If we really can't get rid of the duplicity, what should be the policy
for updating the hashtab code? Should the same changes be done
simultaneously to both copies? Or should we change only libsepol and
treat the newrole copy as mostly frozen legacy code?

The thing is, I'd like to make some small changes in them, but I'm not
sure how to handle the duplicity.

Thanks!

-- 
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.

Re: Duplicate hashtab code in libsepol vs. policycoreutils/newrole?

[Stephen Smalley]

On 2/15/20 12:32 PM, Ondrej Mosnacek wrote:
> Hello everyone,
> 
> I noticed that there is a duplicate hashtab.[hc] code from libsepol in
> policycoreutils/newrole. Can this be deduplicated somehow? I can think
> of three options:
> 1. link to libsepol (a bit unsafe, since hashtab symbols are not
> versioned, but other programs already use non-versioned symbols form
> libsepol anyway...),
> 2. statically link with libsepol's hashtab.o (libsepol code would be
> needed in ../../libsepol to build newrole)
> 3. turn the newrole files into symlinks that link to libsepol ones
> (similar issue as above, the symlinks would have to be substituted for
> actual files when creating release archive).

I'd say none of the above. Nothing should be using a non-versioned 
symbol from libsepol unless it is statically linking libsepol, and we 
don't want to grow the set of users of the static libsepol (if anything 
we want to shrink that set).  We also don't want to create extraneous 
dependencies.

> If we really can't get rid of the duplicity, what should be the policy
> for updating the hashtab code? Should the same changes be done
> simultaneously to both copies? Or should we change only libsepol and
> treat the newrole copy as mostly frozen legacy code?

I'd say the latter - ignore the newrole hashtab.[ch] copy unless/until 
you have a real reason that it requires an update for newrole's sake. 
Treat it as a fork (which it is).

> The thing is, I'd like to make some small changes in them, but I'm not
> sure how to handle the duplicity.