Tags:
create new tag
view all tags

SL7 Development FAQ

EL7 versus SL7

In Informatics we are using SL7 as our target platform but we are trying to recognise the fact that most of what we do is applicable to RHEL7 and any other clone in general (e.g. Centos7). With that in mind we have introduced the idea of a base (which is EL7) for the platform (which is SL7). Unless you know that something you are working on genuinely only works on SL7 then you should target EL7. That means, for instance, that the macro to use in headers is LINUX_EL7. Package list names vary depending on their purpose, the main "lcfg" lists are aimed at EL7 (e.g. lcfg_el7_lcfg.rpms) but there are also platform-specific lists (e.g. lcfg_sl70_base.rpms) which will change for each minor release. The information is exposed via the SysInfo component, see SystemInformation for details.

How to call daemon methods?

SL7 has introduced SystemD which replaces upstart and the traditional SysVinit style of calling methods for daemons (e.g. stop, start, reload). To make it easier for LCFG component authors and avoid code duplication, we have introduced a new ngeneric Service method which hides the implementation details and works on all supported platforms. Full details are available at ControllingDaemons.

Fails to build due to missing documentation files

There are two reasons why your package might fail to build because of missing documentation files.

1. Missing build dependencies

The first cause is that the pod2man and podselect tools are no longer provided as part of the core perl package. This problem is likely to be seen when building with PkgForge but not on your EL7 development machine. This means that you now need to explicitly specify BuildRequires for these tools. The simplest solution is to add:

BuildRequires: lcfg-build-deps

which introduces a build-dependency on the new lcfg-build-deps meta-package. That will guarantee that you have all the standard tools necessary to build LCFG packages, see BuildDependencies for more details.

2. Empty pod files no longer created

Due to a bug in the version of pod2man on SL6, Perl modules which did not contain any documentation would still cause the creation an empty .pod file. This is typically an issue with nagios translator modules (e.g. nagios/foo.pm) and components which are written as modules (e.g. lib/LCFG/Component/Foo.pm.cin). You will need to alter the %files section of your specfile so that it no longer refers to these empty files. The fly-in-the-ointment with this approach is that it would then prevent building the package on SL6 so you also need to add to the %install section something like this:

# Remove empty files (because pod2man on SL6 wrongly creates empty man pages)
find $RPM_BUILD_ROOT -type f -empty -print0 | xargs --null --no-run-if-empty rm

Anywhere after the call to make install in that section will do, see lcfg-cron for example.

-- Main.squinney - 2014-11-03

Topic revision: r1 - 2014-11-03 - squinney
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback