[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Bugfixes in EPEL via rebases to latest upstream?

On Thu, Oct 18, 2012 at 01:39:23AM -0700, Toshio Kuratomi wrote:
> 		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.


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

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?

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

> * Requiring common RHEL configurations to be changed in order to run: to be
>   avoided if possible but allowable if there's no other way.

Again, the other way here was to fix the packaging.

> * Disabling features to support common RHEL configurations: allowable
>   (encouraged if it solves the previous issue).


Thank you,

Jan Pazdziora | adelton at #satellite*, #brno
Principal Software Engineer, Satellite Engineering, Red Hat

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]