On Sun, Mar 1, 2020 at 8:53 PM William Roberts <bill.c.roberts@xxxxxxxxx> wrote: > > On Sun, Mar 1, 2020 at 1:25 PM Nicolas Iooss <nicolas.iooss@xxxxxxx> wrote: > > > > On Fri, Feb 28, 2020 at 2:32 PM <bill.c.roberts@xxxxxxxxx> wrote: > > > > > > From: William Roberts <william.c.roberts@xxxxxxxxx> > > > > > > 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
