hi
now that EPEL has moved out of beta, what are the next steps needed to get epel-release included in CentOS-Extras.
- KB
On 09/02/2014 08:16 AM, Karanbir Singh wrote:
hi
now that EPEL has moved out of beta, what are the next steps needed to get epel-release included in CentOS-Extras.
- KB
Re-signing the package with the centos key, and then adding it to the repo. I don't see a need to do anything else.
On Tue, Sep 2, 2014 at 6:25 AM, Jim Perrin jperrin@centos.org wrote:
On 09/02/2014 08:16 AM, Karanbir Singh wrote:
hi
now that EPEL has moved out of beta, what are the next steps needed to get epel-release included in CentOS-Extras.
- KB
Re-signing the package with the centos key, and then adding it to the repo. I don't see a need to do anything else.
I think it's also worth considering if you want %config or %config(noreplace) for the .repo file in the package. We touched on this briefly in the EPEL meeting and Ansii opened a bug to track it: https://bugzilla.redhat.com/show_bug.cgi?id=1135576
FWIW, epel-release-6 is %config(noreplace) on the repo file -- meaning it won't overwrite user-modified repo files. It might be worthwhile to have %config for the initial release of epel-release-7 (specifically to ensure that "gpgcheck=1" gets added), but after that I'd rather see it as "noreplace". I'll comment on the bug to see if we can get that sorted out.
-Jeff
On 09/02/2014 03:01 PM, Jeff Sheltren wrote:
On Tue, Sep 2, 2014 at 6:25 AM, Jim Perrin <jperrin@centos.org mailto:jperrin@centos.org> wrote:
On 09/02/2014 08:16 AM, Karanbir Singh wrote: > hi > > now that EPEL has moved out of beta, what are the next steps needed to > get epel-release included in CentOS-Extras. > > - KB > Re-signing the package with the centos key, and then adding it to the repo. I don't see a need to do anything else.I think it's also worth considering if you want %config or %config(noreplace) for the .repo file in the package. We touched on this briefly in the EPEL meeting and Ansii opened a bug to track it: https://bugzilla.redhat.com/show_bug.cgi?id=1135576
FWIW, epel-release-6 is %config(noreplace) on the repo file -- meaning it won't overwrite user-modified repo files. It might be worthwhile to have %config for the initial release of epel-release-7 (specifically to ensure that "gpgcheck=1" gets added), but after that I'd rather see it as "noreplace". I'll comment on the bug to see if we can get that sorted out.
that would be a good thing to get in - i think the config files should survive a rpm update for site customisations.
On Tue, Sep 2, 2014 at 9:05 AM, Karanbir Singh mail-lists@karan.org wrote:
FWIW, epel-release-6 is %config(noreplace) on the repo file -- meaning it won't overwrite user-modified repo files. It might be worthwhile to have %config for the initial release of epel-release-7 (specifically to ensure that "gpgcheck=1" gets added), but after that I'd rather see it as "noreplace". I'll comment on the bug to see if we can get that sorted out.
that would be a good thing to get in - i think the config files should survive a rpm update for site customisations.
I spoke with Jim about this on IRC and he and I are in agreement that it's best to sort it out within EPEL instead of having CentOS make any changes to the package.
-Jeff
On Tue, 2 Sep 2014 09:10:20 -0700 Jeff Sheltren jeff@tag1consulting.com wrote:
On Tue, Sep 2, 2014 at 9:05 AM, Karanbir Singh mail-lists@karan.org wrote:
FWIW, epel-release-6 is %config(noreplace) on the repo file -- meaning it won't overwrite user-modified repo files. It might be worthwhile to have %config for the initial release of epel-release-7 (specifically to ensure that "gpgcheck=1" gets added), but after that I'd rather see it as "noreplace". I'll comment on the bug to see if we can get that sorted out.
that would be a good thing to get in - i think the config files should survive a rpm update for site customisations.
I spoke with Jim about this on IRC and he and I are in agreement that it's best to sort it out within EPEL instead of having CentOS make any changes to the package.
I just submitted an epel-release update. Testing and karma welcome.
kevin
On Tue, Sep 2, 2014 at 9:22 AM, Kevin Fenzi kevin@scrye.com wrote:
I just submitted an epel-release update. Testing and karma welcome.
Awesome, thanks Kevin!
-Jeff
Jim Perrin wrote:
On 09/02/2014 08:16 AM, Karanbir Singh wrote:
hi
now that EPEL has moved out of beta, what are the next steps needed to get epel-release included in CentOS-Extras.
- KB
Re-signing the package with the centos key, and then adding it to the repo. I don't see a need to do anything else.
What about some kind of preconfigured protection of base repositories? Epel doesn't live up to their own standards of not replacing system packages:
# yum -d3 update | grep epel
--> advancecomp-1.19-1.el7.x86_64 from epel excluded (priority) --> itstool-2.0.2-1.el7.noarch from epel excluded (priority) --> libntlm-1.3-0.6.el7.x86_64 from epel excluded (priority) --> libntlm-devel-1.3-0.6.el7.x86_64 from epel excluded (priority) --> libvncserver-0.9.9-0.9.el7.x86_64 from epel excluded (priority) --> libvncserver-devel-0.9.9-0.9.el7.x86_64 from epel excluded (priority) --> perl-Crypt-PasswdMD5-1.3-0.16.el7.noarch from epel excluded (priority) --> perl-LWP-Protocol-https-6.04-3.el7.noarch from epel excluded (priority) --> perl-Mozilla-CA-20130114-4.el7.noarch from epel excluded (priority) --> python-mako-0.7.3-1.el7.noarch from epel excluded (priority) --> python-webob-1.2.3-8.el7.noarch from epel excluded (priority)
# yum list python-webob
Installed Packages python-webob.noarch 1.2.3-6.el7 @base
And for epel 5 and epel 6 this list is much longer.
-Michael
On Tue, Sep 2, 2014 at 11:24 AM, Michael Lampe mlampe0@googlemail.com wrote:
What about some kind of preconfigured protection of base repositories? Epel doesn't live up to their own standards of not replacing system packages:
# yum -d3 update | grep epel
--> advancecomp-1.19-1.el7.x86_64 from epel excluded (priority)
(etc.)
Isn't this something that should really be automated with some kind of scanning at the repository level (for both package and file name conflicts)?
On 09/02/2014 05:37 PM, Les Mikesell wrote:
On Tue, Sep 2, 2014 at 11:24 AM, Michael Lampe mlampe0@googlemail.com wrote:
What about some kind of preconfigured protection of base repositories? Epel doesn't live up to their own standards of not replacing system packages:
# yum -d3 update | grep epel
--> advancecomp-1.19-1.el7.x86_64 from epel excluded (priority)
(etc.)
Isn't this something that should really be automated with some kind of scanning at the repository level (for both package and file name conflicts)?
yes it should be possible to automate this test, lets see if we can have a go.
Les Mikesell wrote:
On Tue, Sep 2, 2014 at 11:24 AM, Michael Lampe mlampe0@googlemail.com wrote:
What about some kind of preconfigured protection of base repositories? Epel doesn't live up to their own standards of not replacing system packages:
# yum -d3 update | grep epel
--> advancecomp-1.19-1.el7.x86_64 from epel excluded (priority)
(etc.)
Isn't this something that should really be automated with some kind of scanning at the repository level (for both package and file name conflicts)?
What if some package from epel gets included by RH with an update? This happened several times in the past and epel always kept their package available, even if had a higher version number than the now official RH package.
-Michael
On 2 September 2014 11:14, Michael Lampe mlampe0@googlemail.com wrote:
Les Mikesell wrote:
On Tue, Sep 2, 2014 at 11:24 AM, Michael Lampe mlampe0@googlemail.com wrote:
What about some kind of preconfigured protection of base repositories?
Epel doesn't live up to their own standards of not replacing system packages:
# yum -d3 update | grep epel
--> advancecomp-1.19-1.el7.x86_64 from epel excluded (priority)
(etc.)
Isn't this something that should really be automated with some kind of scanning at the repository level (for both package and file name conflicts)?
What if some package from epel gets included by RH with an update? This happened several times in the past and epel always kept their package available, even if had a higher version number than the now official RH package.
That should not happen (but it does because we aren't connected to what is in releases so end up with surprises every dot release) . Our process is meant to be the following:
1) Put package in EPEL. 2) At dot release make sure packages are not in core. 3) If in core, remove or move our package to a NEVR that won't be replaced by in-stream package.
One problem is that there are many many sub-channels for RHEL of which we only counted a couple as 'core' because we had access to them on a general Enterprise account. We then end up with packages which are different from shipped packages because rhel-some-channel-6.5 had a package which conflicts with EPEL. At the moment, we are looking at having a 'if it is in Base CentOS we aren't going to conflict.' policy. This will take some doing still but should allow for us to clean up our act.
The secondary problem is that if you had package-1.2.4-8 and RHEL releases its next dot release with package-1.2.3-6.. you are stuck with the version EPEL had in it and nothing can be done about it. We can remove it from the repo but your system will have a version which won't see any updates. That is the nature of secondary channels.. and I don't see anything but a yum plugin which says 'base channel has newer but older package in it please rebase'
-Michael
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Tue, Sep 2, 2014 at 12:24 PM, Stephen John Smoogen smooge@gmail.com wrote:
Isn't this something that should really be automated with some kind of scanning at the repository level (for both package and file name conflicts)?
What if some package from epel gets included by RH with an update? This happened several times in the past and epel always kept their package available, even if had a higher version number than the now official RH package.
That should not happen (but it does because we aren't connected to what is in releases so end up with surprises every dot release) . Our process is meant to be the following:
Isn't there a tool that would tell you if you tried to add duplicate packages or packages containing duplicate filenames in your own repo? And if so, can it be modified to work with the metadata from additional repositories? I think it would be great if there were some central database view of all the popular 3rd party repo contents showing 'if you install package x from repo y, you will have conflcts with repo z" (etc.). Instead of having to wait until after installing and finding out the hard way.
But in particular, EPEL needs it to work against RHEL if they want to be honest about their own policy statement (again, without waiting for someone to find out the hard way and report it).
On Tue, 2 Sep 2014 12:40:56 -0500 Les Mikesell lesmikesell@gmail.com wrote:
...snip...
But in particular, EPEL needs it to work against RHEL if they want to be honest about their own policy statement (again, without waiting for someone to find out the hard way and report it).
EPEL is 'best effort'. If you would like to help us, you are welcome to do so. Some things that could help us:
* Someone writing such a tool as you describe.
* Folks actually filing bugs when they see overlapping packages so we can remove them from epel (instead of posting about them where maintainers are unlikely to see them and retire their epel packages).
Thanks and I look forward to the folks coming in to help.
kevin
On Tue, Sep 2, 2014 at 12:51 PM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 2 Sep 2014 12:40:56 -0500 Les Mikesell lesmikesell@gmail.com wrote:
...snip...
But in particular, EPEL needs it to work against RHEL if they want to be honest about their own policy statement (again, without waiting for someone to find out the hard way and report it).
EPEL is 'best effort'. If you would like to help us, you are welcome to do so. Some things that could help us:
Then do you mind adding that to the policy statement - that people can't count on not overwriting base packages?
On Tue, 2 Sep 2014 13:04:47 -0500 Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Sep 2, 2014 at 12:51 PM, Kevin Fenzi kevin@scrye.com wrote:
On Tue, 2 Sep 2014 12:40:56 -0500 Les Mikesell lesmikesell@gmail.com wrote:
...snip...
But in particular, EPEL needs it to work against RHEL if they want to be honest about their own policy statement (again, without waiting for someone to find out the hard way and report it).
EPEL is 'best effort'. If you would like to help us, you are welcome to do so. Some things that could help us:
Then do you mind adding that to the policy statement - that people can't count on not overwriting base packages?
Sure, I can bring that up at our next meeting.
kevin
On Tue, Sep 2, 2014 at 1:11 PM, Kevin Fenzi kevin@scrye.com wrote:
EPEL is 'best effort'. If you would like to help us, you are welcome to do so. Some things that could help us:
Then do you mind adding that to the policy statement - that people can't count on not overwriting base packages?
Sure, I can bring that up at our next meeting.
Thanks - I've been burned before by EPEL's tendency to add packages long after they have been available in other 3rd party repositories but with different/conflicting configurations, but had so far just taken it on faith that there would not be conflicts with base packages.
But - can someone familiar with repository maintenance tools comment on the metadata available and the difficulty of doing conflict checking across multiple repos?
Kevin Fenzi wrote:
EPEL is 'best effort'. ...
Correct. Some things will always be delayed or are actually never done. That's why I have configured priorities also for epel and suggested to do something like this for the centos copy.
- Folks actually filing bugs when they see overlapping packages so we can remove them from epel (instead of posting about them where maintainers are unlikely to see them and retire their epel packages).
epel 5 has about 100 and epel 6 has about 75 packages filtered out with respect to base by priorities. With this in mind I wasn't expecting anything different from epel 7. So: please forgive me for not having filed these and the 175 ones before.
-Michael
On Tue, 02 Sep 2014 20:10:05 +0200 Michael Lampe mlampe0@googlemail.com wrote:
Kevin Fenzi wrote:
EPEL is 'best effort'. ...
Correct. Some things will always be delayed or are actually never done. That's why I have configured priorities also for epel and suggested to do something like this for the centos copy.
- Folks actually filing bugs when they see overlapping packages so
we can remove them from epel (instead of posting about them where maintainers are unlikely to see them and retire their epel packages).
epel 5 has about 100 and epel 6 has about 75 packages filtered out with respect to base by priorities. With this in mind I wasn't expecting anything different from epel 7. So: please forgive me for not having filed these and the 175 ones before.
it's actually also not that simple.
A number of these are added to epel because rhel doesn't ship them on all arches.
https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages
So, all those need filtering out first.
kevin
On 09/02/2014 12:14 PM, Michael Lampe wrote:
Les Mikesell wrote:
On Tue, Sep 2, 2014 at 11:24 AM, Michael Lampe mlampe0@googlemail.com wrote:
What about some kind of preconfigured protection of base repositories? Epel doesn't live up to their own standards of not replacing system packages:
# yum -d3 update | grep epel
--> advancecomp-1.19-1.el7.x86_64 from epel excluded (priority)
(etc.)
While it's certainly not true in all cases, quite a few of the 'excluded' packages come from owning a common directory rather than actual conflicting files. We found a few of these early on during our testing with 7. Of the ones we found (at the time) none actually conflicted, but were excluded due to shared ownership of a plugin directory like /usr/lib/python2.7/site-packages
These should still certainly be corrected.
Isn't this something that should really be automated with some kind of scanning at the repository level (for both package and file name conflicts)?
What if some package from epel gets included by RH with an update? This happened several times in the past and epel always kept their package available, even if had a higher version number than the now official RH package.
This shouldn't happen, and its stuff like this that we'll be working to address in the future. The EPEL Steering Committee has been reformed[1], and one of the topics has been a cleanup and better documentation of epel policy[2].
So this sort of thing should be minimized moving forward.
1. https://lists.fedoraproject.org/pipermail/epel-devel/2014-August/010060.html
2. https://lists.fedoraproject.org/pipermail/epel-devel/2014-August/009943.html
On 2 September 2014 10:24, Michael Lampe mlampe0@googlemail.com wrote:
Jim Perrin wrote:
On 09/02/2014 08:16 AM, Karanbir Singh wrote:
hi
now that EPEL has moved out of beta, what are the next steps needed to get epel-release included in CentOS-Extras.
- KB
Re-signing the package with the centos key, and then adding it to the repo. I don't see a need to do anything else.
What about some kind of preconfigured protection of base repositories? Epel doesn't live up to their own standards of not replacing system packages:
Ooops. I would have preferred to have learned of this on the mailing list before we moved out of beta and also on the epel-devel list. I will work on getting these cleaned up.
# yum -d3 update | grep epel
--> advancecomp-1.19-1.el7.x86_64 from epel excluded (priority) --> itstool-2.0.2-1.el7.noarch from epel excluded (priority) --> libntlm-1.3-0.6.el7.x86_64 from epel excluded (priority) --> libntlm-devel-1.3-0.6.el7.x86_64 from epel excluded (priority) --> libvncserver-0.9.9-0.9.el7.x86_64 from epel excluded (priority) --> libvncserver-devel-0.9.9-0.9.el7.x86_64 from epel excluded (priority) --> perl-Crypt-PasswdMD5-1.3-0.16.el7.noarch from epel excluded (priority) --> perl-LWP-Protocol-https-6.04-3.el7.noarch from epel excluded (priority) --> perl-Mozilla-CA-20130114-4.el7.noarch from epel excluded (priority) --> python-mako-0.7.3-1.el7.noarch from epel excluded (priority) --> python-webob-1.2.3-8.el7.noarch from epel excluded (priority)
# yum list python-webob
Installed Packages python-webob.noarch 1.2.3-6.el7 @base
And for epel 5 and epel 6 this list is much longer.
All I can say is '#%#@$@#D' and I am sorry. We just cleaned these up a short time ago, and there was supposed to be a job which runs to make sure these conflicts don't happen.
-Michael
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 09/02/2014 05:47 PM, Stephen John Smoogen wrote:
All I can say is '#%#@$@#D' and I am sorry. We just cleaned these up a short time ago, and there was supposed to be a job which runs to make sure these conflicts don't happen.
is the code for this available ? if so - we can integrate it at ci.dev.centos.org as well, so its always running ( including just before we push an update, just in case a new package changes something )
On 2 September 2014 10:51, Karanbir Singh mail-lists@karan.org wrote:
On 09/02/2014 05:47 PM, Stephen John Smoogen wrote:
All I can say is '#%#@$@#D' and I am sorry. We just cleaned these up a short time ago, and there was supposed to be a job which runs to make sure these conflicts don't happen.
is the code for this available ? if so - we can integrate it at ci.dev.centos.org as well, so its always running ( including just before we push an update, just in case a new package changes something )
I am looking to see what state it is in. It was something Seth was working on a long time ago and I thought it was integrated but seems I was wrong.
-
Christoph Galuschka -
Jeff Sheltren -
Jim Perrin -
Karanbir Singh -
Kevin Fenzi -
Les Mikesell -
Michael Lampe -
Stephen John Smoogen