Bugfixes in EPEL via rebases to latest upstream?

[Toshio Kuratomi]

On Thu, Oct 18, 2012 at 11:46:08AM +0200, Jan Pazdziora wrote:
> 
> In general case they are not. In the context of this package and this
> bugzilla thou, you confirmed above that in the case upstream does not
> have the fix (and it will not have the fix because of stated upstream's
> policy), the primary path to resolution should have been fixing the
> packaging and rebuilding the same version of upstream .tar.gz with
> bumped up release and with the packaging fix. Am I reading it right?
> 
The bugzilla entry doesn't give me history before the bug.  If the
maintainer rebased to a new upstream version to fix a different bug, then
it's something that's within their discretion to do.  If they knew about the
incompatibility with SELinux in the new version and the workaround, they
probably should have performed the workaround in packaging but they likely
didn't think about the workaround as being a possibility at first (It
doesn't directly speak to the core issue: python wants to execute a file in
a temp dir so it's not obvious that this is something we could do in
packaging).

> Of course, nothing stops the maintainer to do compatible rebase but
> in that case I'd expect that care would be taken to test that
> especially things that were broken in the past (SELinux enforcing)
> don't get broken with the upgrade.
> 
I don't agree with this but I'm not sure that you didn't make a typo here
:-)

I would agree with "I'd expect that care would be taken to test that
especially things which had been fixed in the past (SELinux enforcing) don't
get re-broken with the upgrade."

> >						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.
> 
> That "if possible" alternative in this case is respin the package with
> the extra directory or with the missing module.
> 
AFAICS, the opposite here as well.  In the package, remove the optional
module in our package.

-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/62dbcb58/attachment.sig>