Bugfixes in EPEL via rebases to latest upstream?

[Toshio Kuratomi]

On Thu, Oct 18, 2012 at 09:48:22AM +0200, Jan Pazdziora wrote:
> 
> Hello,
> 
> this is a followup to my FESCo ticket
> 
> 	https://fedorahosted.org/fesco/ticket/959
> 
> 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
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=838898
> 	
> 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
exists.

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, 
>
No.

> 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?
>
Also no.

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
I can:

* 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).

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121018/8662aaaf/attachment.sig>