On Thu, Oct 18, 2012 at 09:48:22AM +0200, Jan Pazdziora wrote:
this is a followup to my FESCo ticket
where I've been advised to ask on epel-devel-list.
I feel there is an issue with the way cobbler package in EPEL gets
maintained. Since the upgrade to cobbler 2.2, any bugzillas reported
against cobbler (many of which are SELinux-related issues) are
addressed by rebasing to latest upstream version.
IMHO, when we setup EPEL, this portion was left up to the maintainer of
a package to decide. Although making backports to support backwards compat
was desirable, maintainers had the option to upgrade to fix issues. This is
not the same as either RHEL or Fedora and is the product of us being
a volunteer effort (thus, sometimes having to sacrifice backwards compat for
better maintainability) but trying to target enterprise linux (where
backwards compat should not be surrendered without some reason).
The ticket, however seems to have more to it than this general question:
>From the ticket: The bugzilla
is a typical example of the problem. The way I read it, maintainer
plans to keep rebasing the package (when cobbler includes a new
feature it will most likely break with SELinux enabled) while not
attempting to integrate with the rest of the RHEL + EPEL distribution
properly (What we DO recommend is that you disable SELinux unless you
are comfortable writing policy). He furthermore recommends EPEL users
to clean up the mess (how about submitting some patches to either
Dan/Fedora or myself to fix the issue instead).
From reading the bug report, upstream does not have a fix in code that they
can give us. Thus, upgrading is not going to fix this problem. However,
they do have a workaround that we can implement in packaging (removing the
authn_pam.py module). I would say that as EPEL packagers, we should be
addressing bugs in packaging where we can so we should be rmeoving that
module in our package. Telling users to disable SELinux is forcing users to
change a supported feature in the baseos. Instead, we should be applying the
workaround to our packaging to enable it to work with the system as it
Note that the maintainer does not have the responsibility to fix RHEL
packages. However, I did point out in the bug report that there appears to
be a fix to the python package that has ben applied to Fedora 17. If you'd
like to test that that patch would work and then work to get it applied in
a RHEL6 update, we'd eventually not need to apply a workaround here.
Is the maintainer's policy correct and running without enforcing
SELinux is generally accepted,
or should the standard approach
in EPEL be to pick stable upstream version and stay with it, fixing
issues by (ideally) submitting fix to upstream while releasing
patched package with the same version and bumped-up release?
These two options are not diametrically opposed. I hope I explained above
why I don't believe either of them to be true. Let me summarize as best
* Gratuitous backwards incompatible upgrades: prohibit
* Compatible upgrades to fix bugs: allowable
* Backwards incompatible upgrades to fix bugs known to effect EPEL users:
avoid if possible but allowable.
* Requiring common RHEL configurations to be changed in order to run: to be
avoided if possible but allowable if there's no other way.
* Disabling features to support common RHEL configurations: allowable
(encouraged if it solves the previous issue).