Re: [PATCH] libsemanage: check libsepol version

[Nicolas Iooss <nicolas.iooss@m4x.org>]

On Sun, Mar 1, 2020 at 8:53 PM William Roberts <bill.c.roberts@gmail.com> wrote:
>
> On Sun, Mar 1, 2020 at 1:25 PM Nicolas Iooss <nicolas.iooss@m4x.org> wrote:
> >
> > On Fri, Feb 28, 2020 at 2:32 PM <bill.c.roberts@gmail.com> wrote:
> > >
> > > From: William Roberts <william.c.roberts@intel.com>
> > >
> > > If libsepol is older than version 3.0, the required routine
> > > sepol_policydb_optimize will not be present. Use pkg-config to get the
> > > modversion and check that it is 3.0 or higher.
> > >
> > > This can manifest as a compilation issue:
> > > direct_api.c: In function ‘semanage_direct_commit’:
> > > direct_api.c:1466:13: error: implicit declaration of function ‘sepol_policydb_optimize’; did you mean ‘sepol_policydb_to_image’? [-Werror=implicit-function-declaration]
> > >      retval = sepol_policydb_optimize(out);
> > >
> > > Which is not really clear on how to check.
> >
> > >From my point of view, this kind of dependency management is something
> > that is more suited in a package management system than in a Makefile.
> > It makes sense to check for libsepol version if there is some kind of
> > optional features that gets enabled according to it (in a similar way
> > as a --with-... statement in build systems using autoconf) or if there
> > is a fall back to another compatible source code (and the Makefile
> > would "route" the building process to the right .c file). But these
> > reasons do not match what you are doing in this change.
>
> Since we don't use autotools, selinux makefiles have to be smarter. We
> already use
> PKG_CONFIG to get various flags, which would normally be handled in a
> configure script, which if we had autotools, would also be a place to check
> dependency versions.
>
> >
> > Why do you need this patch, instead of stating in the package to use
> > for libsemanage that it depends on libsepol>=3.0?
>
> We should document that as well, but make software smarter, not people.
> If we can provide a better error message, without a huge burden of
> work or maintenance
> I always vote to do it. In this case, it's pretty simple to do, since
> we already have the infrastructure for
> PKG_CONFIG in the Makefiles.

Adding a magic Makefile target which is later removed for a variable
using $(filter-out $<,$^) makes things a little bit more complex, but
I can agree with this.
On the other hand, since I began packaging SELinux libraries for Arch
Linux, I found several releases that needed to bump such a dependency
version. For example, if I remember correctly libsemanage 2.4 requires
libsepol>=2.4, same for 2.5, 2.6... but libsemanage 2.9 could work
with libsepol 2.8 (I usually tries building with older versions when
packaging a release for Arch Linux, and the history is available for
example on https://aur.archlinux.org/cgit/aur.git/log/?h=libsemanage).

This being said, what about adding some logic to force libsemange
version X.Y to depend on libsepol>=X.Y and libselinux>=X.Y? The
version is already available in libsemanage/VERSION and this file
could be used to implement such a check.

Nicolas