[EXCEPTION REQUEST] librepo/libsolv/hawkey override in EPEL7

[Igor Gnatenko]

Hi all,

Sorry for delay for writing this. We wanted to provide latest DNF
stack in EPEL7 which means we also need newer components like libsolv,
hawkey, librepo, etc.

Some of those are in RHEL7.2 and unfortunately it's not that easy to
get them updated:
- librepo
- libsolv
- hawkey

Probably some more, didn't remember. There are no ABI breakage with
those updates and actually only PackageKit (via libhif) depends on it.

So I would like to ask EPSCo to provide exception to override those
packages in EPEL7.

Not sure if maillist is correct way to do this..

[Peter Robinson]

> Sorry for delay for writing this. We wanted to provide latest DNF
> stack in EPEL7 which means we also need newer components like libsolv,
> hawkey, librepo, etc.

Delayed so much you've already pushed them to testing I see.I'd like
to see those unpushed until a decision is made. This isn't "push now,
ask for forgiveness later"
> Some of those are in RHEL7.2 and unfortunately it's not that easy to
> get them updated:
> librepo
> libsolv
> hawkey
>
> Probably some more, didn't remember. There are no ABI breakage with
> those updates and actually only PackageKit (via libhif) depends on it.

For me this is NACK, presumably you've only tested core RHEL
dependences? What about layered products, atomic, compose tools and
third parties that might be using the libraries?
> So I would like to ask EPSCo to provide exception to override those
> packages in EPEL7.
>
> Not sure if maillist is correct way to do this..

There should likely be a ticket with a meeting keyword too but I'm not
sure where the EPSCo ticket instance is, this is a good start.

[Stephen John Smoogen]

On 9 May 2016 at 02:38, Igor Gnatenko  wrote:
> Hi all,
>
> Sorry for delay for writing this. We wanted to provide latest DNF
> stack in EPEL7 which means we also need newer components like libsolv,
> hawkey, librepo, etc.
>
> Some of those are in RHEL7.2 and unfortunately it's not that easy to
> get them updated:
> librepo
> libsolv
> hawkey
>
> Probably some more, didn't remember. There are no ABI breakage with
> those updates and actually only PackageKit (via libhif) depends on it.
>
> So I would like to ask EPSCo to provide exception to override those
> packages in EPEL7.

1. We have never given an exception before that I know of. [I think
openstack asked for an exception but there was too much customer
problems with it to make it possible. ]
2. You could have broken hundreds of thousands of computers (mainly
because they have yum install in their cron jobs it looks like).
Pushing and then asking for permission is not acceptable. It usually
leads to the package set being removed and blacklisted from EPEL.
3. I understand the importance of this package set, and will try to
work with you on this, but I am going to need a day to not be pissed.
> Not sure if maillist is correct way to do this..

It is where this should have started. I realize I am a bit livid, but
I and the other EPSCo committee members are the one who usually have
to spend their off-hours fixing these problems versus doing other
things. [Like writing the software that would have told you that this
package couldn't be put into EPEL without an exception.]
> --
> -Igor Gnatenko
> _______________________________________________
> epel-devel mailing list
> [e-mail]
> http://lists.fedoraproject.org/admin/lists/[e-mail]...

[Peter Robinson]

> > Sorry for delay for writing this. We wanted to provide latest DNF
> > stack in EPEL7 which means we also need newer components like libsolv,
> > hawkey, librepo, etc.
> >
> > Some of those are in RHEL7.2 and unfortunately it's not that easy to
> > get them updated:
> > librepo
> > libsolv
> > hawkey
> >
> > Probably some more, didn't remember. There are no ABI breakage with
> > those updates and actually only PackageKit (via libhif) depends on it.
> >
> > So I would like to ask EPSCo to provide exception to override those
> > packages in EPEL7.
> We have never given an exception before that I know of. [I think
>
> openstack asked for an exception but there was too much customer
> problems with it to make it possible. ]
> 2. You could have broken hundreds of thousands of computers (mainly
> because they have yum install in their cron jobs it looks like).
> Pushing and then asking for permission is not acceptable. It usually
> leads to the package set being removed and blacklisted from EPEL.
> 3. I understand the importance of this package set, and will try to
> work with you on this, but I am going to need a day to not be pissed.

Personally I think the proper place to do this is copr. EPEL really
isn't the place to do it especially if it's "too hard" to work with
the internal teams to get it updated in the appropriate EL release.

Peter

[Kevin Fenzi]

On Mon, 9 May 2016 13:44:41 +0100
Peter Robinson  wrote:
> > > Sorry for delay for writing this. We wanted to provide latest DNF
> > > stack in EPEL7 which means we also need newer components like
> > > libsolv, hawkey, librepo, etc.
> > >
> > > Some of those are in RHEL7.2 and unfortunately it's not that easy
> > > to get them updated:
> > > librepo
> > > libsolv
> > > hawkey
> > >
> > > Probably some more, didn't remember. There are no ABI breakage with
> > > those updates and actually only PackageKit (via libhif) depends on
> > > it.
> > >
> > > So I would like to ask EPSCo to provide exception to override those
> > > packages in EPEL7.
> > We have never given an exception before that I know of. [I think
> >
> > openstack asked for an exception but there was too much customer
> > problems with it to make it possible. ]
> > 2. You could have broken hundreds of thousands of computers (mainly
> > because they have yum install in their cron jobs it looks like).
> > Pushing and then asking for permission is not acceptable. It usually
> > leads to the package set being removed and blacklisted from EPEL.
> > 3. I understand the importance of this package set, and will try to
> > work with you on this, but I am going to need a day to not be
> > pissed.
>
> Personally I think the proper place to do this is copr. EPEL really
> isn't the place to do it especially if it's "too hard" to work with
> the internal teams to get it updated in the appropriate EL release.

Well, that or the traditional way: create parallel installable forward
compat packages and have the dnf in EPEL use them instead of the RHEL
versions, ie, libsolv0.6 etc.

Has that path been explored?

kevin

[Neal Gompa]

On Mon, May 9, 2016 at 9:43 AM, Kevin Fenzi  wrote:
> On Mon, 9 May 2016 13:44:41 +0100
> Peter Robinson  wrote:
> > > > Sorry for delay for writing this. We wanted to provide latest DNF
> > > > stack in EPEL7 which means we also need newer components like
> > > > libsolv, hawkey, librepo, etc.
> > > >
> > > > Some of those are in RHEL7.2 and unfortunately it's not that easy
> > > > to get them updated:
> > > > librepo
> > > > libsolv
> > > > hawkey
> > > >
> > > > Probably some more, didn't remember. There are no ABI breakage with
> > > > those updates and actually only PackageKit (via libhif) depends on
> > > > it.
> > > >
> > > > So I would like to ask EPSCo to provide exception to override those
> > > > packages in EPEL7.
> > > We have never given an exception before that I know of. [I think
> > >
> > > openstack asked for an exception but there was too much customer
> > > problems with it to make it possible. ]
> > > 2. You could have broken hundreds of thousands of computers (mainly
> > > because they have yum install in their cron jobs it looks like).
> > > Pushing and then asking for permission is not acceptable. It usually
> > > leads to the package set being removed and blacklisted from EPEL.
> > > 3. I understand the importance of this package set, and will try to
> > > work with you on this, but I am going to need a day to not be
> > > pissed.
> >
> > Personally I think the proper place to do this is copr. EPEL really
> > isn't the place to do it especially if it's "too hard" to work with
> > the internal teams to get it updated in the appropriate EL release.
>
> Well, that or the traditional way: create parallel installable forward
> compat packages and have the dnf in EPEL use them instead of the RHEL
> versions, ie, libsolv0.6 etc.
>
> Has that path been explored?

They would still conflict on files, since libsolv uses the same
soversion and have the same binary compatibility. I suppose if the
build was patched to use a different library name, it could work.

[Kevin Fenzi]

On Mon, 9 May 2016 09:52:00 -0400
Neal Gompa  wrote:
> They would still conflict on files, since libsolv uses the same
> soversion and have the same binary compatibility. I suppose if the
> build was patched to use a different library name, it could work.

Yes, that would be part of making it parallel installable. ;)

kevin

[Stephen John Smoogen]

On 9 May 2016 at 08:29, Stephen John Smoogen  wrote:
> On 9 May 2016 at 02:38, Igor Gnatenko  wrote:
> > Hi all,
> >
> > Sorry for delay for writing this. We wanted to provide latest DNF
> > stack in EPEL7 which means we also need newer components like libsolv,
> > hawkey, librepo, etc.
> >
> > Some of those are in RHEL7.2 and unfortunately it's not that easy to
> > get them updated:
> > librepo
> > libsolv
> > hawkey
> >
> > Probably some more, didn't remember. There are no ABI breakage with
> > those updates and actually only PackageKit (via libhif) depends on it.
> >
> > So I would like to ask EPSCo to provide exception to override those
> > packages in EPEL7.
> We have never given an exception before that I know of. [I think
>
> openstack asked for an exception but there was too much customer
> problems with it to make it possible. ]
> 2. You could have broken hundreds of thousands of computers (mainly
> because they have yum install in their cron jobs it looks like).
> Pushing and then asking for permission is not acceptable. It usually
> leads to the package set being removed and blacklisted from EPEL.
> 3. I understand the importance of this package set, and will try to
> work with you on this, but I am going to need a day to not be pissed.

OK feeling a lot less peeved. In any case, we haven't done over-rides
in the past because we have a 'no replacing Red Hat Enterprise Linux'
as a core tenant of the EPEL repository. The ways that we do this is
have these packages be parallel install-able packages versus
replacement packages.