Main difference for a package maintainer (I think that would be 'developer' in Debian lingo) is the way package meta-data and accompanying scripts come together.
In the RPM world, all your packages (the RPMs you maintain) are located in something like ~/rpmbuild
. Underneath, there is the SPEC
directory for your spec-files, a SOURCES
directory for source tarballs, RPMS
and SRPMS
directories to put newly created RPMs and SRPMs into, and some other things that are not relevant now.
Everything that has to do with how the RPM will be created is in the spec-file: what patches will be applied, possible pre- and post-scripts, meta-data, changelog, everything. All source tarballs and all patches of all your packages are in SOURCES.
Now, personally, I like the fact that everything goes into the spec-file, and that the spec-file is a separate entity from the source tarball, but I'm not overly enthusiastic about having all sources in SOURCES. IMHO, SOURCES gets cluttered pretty quick and you tend to lose track of what is in there. However, opinions differ.
For RPMs it is important to use the exact same tarball as the one the upstream project releases, up to the timestamp. Generally, there are no exceptions to this rule. Debian packages also require the same tarball as upstream, though Debian policy requires some tarballs to be repackaged (thanks, Umang).
Debian packages take a different approach. (Forgive any mistakes here: I am a lot less experienced with deb's that I am with RPM's.) Debian packages' development files are contained in a directory per package.
What I (think to) like about this approach is the fact that everything is contained in a single directory.
In the Debian world, it is a bit more accepted to carry patches in a package that are not (yet) upstream. In the RPM world (at least among the Red Hat derivatives) this is frowned upon. See "FedoraProject: Staying close to upstream projects".
Also, Debian has a vast amount of scripts that are able to automate a huge portion of creating a package. For example, creating a - simple - package of a setuptool'ed Python program, is as simple as creating a couple of meta-data files and running debuild
. That said, the spec-file for such package in RPM format would be pretty short and in the RPM world, too, there's a lot of stuff that is automated these days.
The Fedora Packaging Guidelines have a draft document explaining how to handle SELinux in packages, and they use semanage
. Without semanage
, it looks like supporting RHEL 4 is going to be a hack, and there's no way around that.
According to the rpm 4.9.0 release notes, there has been some support directly in rpm for managing SELinux policies, but it has historically been broken:
- Older versions of RPM supported a %policy directive in spec for attaching SELinux policies into the package header, but this was never really usable for anything. Any uses of the %policy directive in specs should be removed as this unused directive prevents building with RPM 4.9.0 and later, while not doing anything for older versions.
- Starting with RPM 4.9.0, SELinux policy packaging is supported via new %sepolicy section in the spec. Such packages cannot be built, but are installable on older RPM versions too (but the included policies will not be used in any way).
I see no mention of file contexts there, and I haven't been able to find any mention of direct file context support (like %attr
in the %files
section). In any case, it looks like RHEL 6 is only on rpm 4.8.0, so (unless I've missed something) the semanage
route is as good as we're going to be able to do at least until RHEL 7.
Best Answer
SELinux configuration is provided by
selinux-policy-targeted
package, which contains the default policy configuration for the distribution, including SELinux configuration for tomcat.I could find two old Fedora packaging drafts describing SELinux configuration in RPM packaging.
PackagingDrafts/SELinux suggests including the file labeling configuration in
%post
and%postun
sections of the spec file by executingsemanage fcontext -a
andsemanage fcontext -d
respectively and runningrestorecon
/fixfiles
afterwards.It is useful to note, as pointed out by Graham Legett, that using
semanage
in%pre
or%post
sections of spec will add the complete python stack along withpolicycoreutils-python
as install time dependency. Usingrestorecon
will addpolicycoreutils
, which in turn brings insed
,gawk
andgrep
, as install time dependencies.A better way to provide the required file labeling rules would be by a SELinux policy module. Policy modules provide clearer interface to manage modular policy (labeling rules are not mixed with local modifications done with
semanage
).For your policy module with file labeling rules, you need to provide type enforcement file and file context labeling file. Type enforcement file is required even if you do not add any modifications to the policy. An example dummy type enforcement file
mymodule.te
:The file labeling rules are in
mymodule.fc
and follow same :With
selinux-policy-devel
, the module package can be compiled with[note 1]:Regarding packaging policy modules, SELinux Policy Modules Packaging Draft similarly recommends using the
%post
and%postun
sections of the spec file to install the policy usingsemodule
andrestorecon
/fixfiles
. An example spec file is also provided.[note 1] The example policy module could be generated without
selinux-policy-devel
by usingcheckmodule
andsemodule_package
directly. It would require the policy files to be written without macros.