Hello,
There isn't many of them, but yum and related packages are in Centos and not in RHEL-4 (unless I am wrong). Should they be packaged in EPEL or not?
And in the general, what to do in such cases?
-- Pat
On Jul 7, 2007, at 10:00 AM, Patrice Dumas wrote:
Hello,
There isn't many of them, but yum and related packages are in Centos and not in RHEL-4 (unless I am wrong).
According to the CentOS release notes, you are correct: http://mirror.centos.org/centos/4/os/i386/RELEASE-NOTES-en.html
It lists the following as packages which are in CentOS-4 and not in RHEL-4: createrepo centos-yumconf sqlite sqlite-devel python-elementtree python-sqlite python-urlgrabber yum
'centos-yumconf' is probably safe to ignore as it is only yum repo configs. We should discuss how to deal with the other packages.
-Jeff
On 07/07/2007 05:15 PM, Jeff Sheltren wrote:
On Jul 7, 2007, at 10:00 AM, Patrice Dumas wrote:
Hello,
There isn't many of them, but yum and related packages are in Centos and not in RHEL-4 (unless I am wrong).
According to the CentOS release notes, you are correct: http://mirror.centos.org/centos/4/os/i386/RELEASE-NOTES-en.html
It lists the following as packages which are in CentOS-4 and not in RHEL-4: createrepo centos-yumconf sqlite sqlite-devel python-elementtree python-sqlite python-urlgrabber yum
'centos-yumconf' is probably safe to ignore as it is only yum repo configs. We should discuss how to deal with the other packages.
I for one am 100% in favor of including them in EPEL. At least because RH5 uses yum.
On 7/7/07, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 07/07/2007 05:15 PM, Jeff Sheltren wrote:
On Jul 7, 2007, at 10:00 AM, Patrice Dumas wrote:
Hello,
There isn't many of them, but yum and related packages are in Centos and not in RHEL-4 (unless I am wrong).
According to the CentOS release notes, you are correct: http://mirror.centos.org/centos/4/os/i386/RELEASE-NOTES-en.html
It lists the following as packages which are in CentOS-4 and not in RHEL-4: createrepo centos-yumconf sqlite sqlite-devel python-elementtree python-sqlite python-urlgrabber yum
'centos-yumconf' is probably safe to ignore as it is only yum repo configs. We should discuss how to deal with the other packages.
I for one am 100% in favor of including them in EPEL. At least because RH5 uses yum.
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
I thought we have had this conversation before and said that native tools woudl be used. (I.E on RHEL 4, you get to have all the fun of up2date (shudder)) . I am not saying I am for or against, but we have had the conversation.
stahnma
On Jul 7, 2007, at 3:56 PM, Michael Stahnke wrote:
I thought we have had this conversation before and said that native tools woudl be used. (I.E on RHEL 4, you get to have all the fun of up2date (shudder)) . I am not saying I am for or against, but we have had the conversation.
stahnma
Did the question of what to do when someone wants, for example, sqlite (or needs it for a dependency)?
Sorry, I must have missed this before :)
-Jeff
On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote:
But then EPEL conflicts with Centos.
Why not just track their package with a lower Release?
Steve
On 07.07.2007 16:32, Manuel Wolfshant wrote:
On 07/07/2007 05:15 PM, Jeff Sheltren wrote:
On Jul 7, 2007, at 10:00 AM, Patrice Dumas wrote:
There isn't many of them, but yum and related packages are in Centos and not in RHEL-4 (unless I am wrong).
According to the CentOS release notes, you are correct: http://mirror.centos.org/centos/4/os/i386/RELEASE-NOTES-en.html
It lists the following as packages which are in CentOS-4 and not in RHEL-4: createrepo centos-yumconf sqlite sqlite-devel python-elementtree python-sqlite python-urlgrabber yum
'centos-yumconf' is probably safe to ignore as it is only yum repo configs. We should discuss how to deal with the other packages.
I for one am 100% in favor of including them in EPEL. At least because RH5 uses yum.
+1 (except centos-yumconf of course)
But we should not create trouble for CentOS, so I'm in favor of this, what was said somewhere else in this thread:
On 07.07.2007 22:58, Steven Pritchard wrote:
On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote:
But then EPEL conflicts with Centos.
Why not just track their package with a lower Release?
CU thl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 8, 2007, at 9:23 AM, Thorsten Leemhuis wrote:
On 07.07.2007 16:32, Manuel Wolfshant wrote:
I for one am 100% in favor of including them in EPEL. At least because RH5 uses yum.
+1 (except centos-yumconf of course)
But we should not create trouble for CentOS, so I'm in favor of this, what was said somewhere else in this thread:
On 07.07.2007 22:58, Steven Pritchard wrote:
On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote:
But then EPEL conflicts with Centos.
Why not just track their package with a lower Release?
CU thl
I have rebuilt the following packages by using those included in CentOS 4.5 and prepending a '0' to the release tag (and in some cases, adding a dist tag): createrepo python-elementtree python-sqlite python-urlgrabber sqlite yum
For the yum package I also made a change to the yum.conf file which gets installed so that it looks at redhat-release instead of centos- release. CentOS users should not be installing these packages due to the lower release number, so this should work nicely to allow RHEL 4 users to install yum if needed.
I've put all the SRPMs here: http://www.sheltren.com/epel/packages/ The sha1sums can be found in sha1sums.txt signed with my gpg key.
If these packages look good to everyone, I'm willing to coordinate with the Fedora maintainers to get these into EPEL. If the maintainers don't want to maintain the package in EPEL, I am willing to co-maintain them in EPEL (or have someone else do it if anyone's interested).
Thoughts, questions, comments?
- -Jeff
Thanks for taking some action here. I think it seems like a great idea. Having the abillity to simply install Yum on RHEL 4 will probably make many enterprise customers happy. Additionally, having this as a compatability across RHEL and Centos should only help the EPEL cause.
stahnma
Jeff Sheltren wrote:
On Jul 8, 2007, at 9:23 AM, Thorsten Leemhuis wrote:
On 07.07.2007 16:32, Manuel Wolfshant wrote:
I for one am 100% in favor of including them in EPEL. At least because RH5 uses yum.
+1 (except centos-yumconf of course)
But we should not create trouble for CentOS, so I'm in favor of this, what was said somewhere else in this thread:
On 07.07.2007 22:58, Steven Pritchard wrote:
On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote:
But then EPEL conflicts with Centos.
Why not just track their package with a lower Release?
CU thl
I have rebuilt the following packages by using those included in CentOS 4.5 and prepending a '0' to the release tag (and in some cases, adding a dist tag): createrepo python-elementtree python-sqlite python-urlgrabber sqlite yum
For the yum package I also made a change to the yum.conf file which gets installed so that it looks at redhat-release instead of centos-release. CentOS users should not be installing these packages due to the lower release number, so this should work nicely to allow RHEL 4 users to install yum if needed.
I've put all the SRPMs here: http://www.sheltren.com/epel/packages/ The sha1sums can be found in sha1sums.txt signed with my gpg key.
If these packages look good to everyone, I'm willing to coordinate with the Fedora maintainers to get these into EPEL. If the maintainers don't want to maintain the package in EPEL, I am willing to co-maintain them in EPEL (or have someone else do it if anyone's interested).
Thoughts, questions, comments?
-Jeff
I would like to take the opportunity to publicly thank Jeff and Mike McGrath for discussing this issue with the CentOS developers.
The CentOS devels think that this is a great solution to the problem.
Since I have complained loudly on this list for the lack of collaboration in the past, I figured I should also praise a good effort too.
Thanks, Johnny Hughes CentOS Developer
Jeff Sheltren wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 8, 2007, at 9:23 AM, Thorsten Leemhuis wrote:
On 07.07.2007 16:32, Manuel Wolfshant wrote:
I for one am 100% in favor of including them in EPEL. At least because RH5 uses yum.
+1 (except centos-yumconf of course)
But we should not create trouble for CentOS, so I'm in favor of this, what was said somewhere else in this thread:
On 07.07.2007 22:58, Steven Pritchard wrote:
On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote:
But then EPEL conflicts with Centos.
Why not just track their package with a lower Release?
CU thl
I have rebuilt the following packages by using those included in CentOS 4.5 and prepending a '0' to the release tag (and in some cases, adding a dist tag): createrepo python-elementtree python-sqlite python-urlgrabber sqlite yum
For the yum package I also made a change to the yum.conf file which gets installed so that it looks at redhat-release instead of centos-release. CentOS users should not be installing these packages due to the lower release number, so this should work nicely to allow RHEL 4 users to install yum if needed.
I've put all the SRPMs here: http://www.sheltren.com/epel/packages/ The sha1sums can be found in sha1sums.txt signed with my gpg key.
If these packages look good to everyone, I'm willing to coordinate with the Fedora maintainers to get these into EPEL. If the maintainers don't want to maintain the package in EPEL, I am willing to co-maintain them in EPEL (or have someone else do it if anyone's interested).
Thoughts, questions, comments?
- -Jeff
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)
iD8DBQFGpzqJKe7MLJjUbNMRAsm4AJ915q/4ysjAVtWLK7QHipnxBGSRUgCgoPCe q0s2lZ8YsdXykfB5ngAhY1I= =OB3h -----END PGP SIGNATURE-----
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
I haven't looked at these packages yet, but I'm really glad to see this work being done. I mentioned this on #epel a few days ago -- lots of folks will be looking for yum to be there.
The selfish reason for me to want it is that Cobbler (http://cobbler.et.redhat.com) uses it for repository management and is otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not so selfish reason is tons of RHEL4 users are already using yum for various things (including maintaining their own repositories of lots of stuff, including, sometimes, updates) and it would be nice if they could get their yum from EPEL and use yum with EPEL if they wanted.
Thanks!
--Michael DeHaan
On Jul 27, 2007, at 8:48 AM, Michael DeHaan wrote:
I haven't looked at these packages yet, but I'm really glad to see this work being done. I mentioned this on #epel a few days ago -- lots of folks will be looking for yum to be there.
The selfish reason for me to want it is that Cobbler (http:// cobbler.et.redhat.com) uses it for repository management and is otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not so selfish reason is tons of RHEL4 users are already using yum for various things (including maintaining their own repositories of lots of stuff, including, sometimes, updates) and it would be nice if they could get their yum from EPEL and use yum with EPEL if they wanted.
Thanks!
--Michael DeHaan
During the EPEL meeting on July 25 -- log here: https://www.redhat.com/archives/epel-devel-list/2007-July/msg00225.html There was some discussion about problems including yum in EPEL.
The first issue was that these packages don't mess up CentOS users. Since these packages all have a lower release than those found in CentOS, that should not be a problem since they should never get installed in the first place.
The second issue was that RHEL 4 users can't use yum for system updates. Do we need to provide a wiki page explaining to RHEL users that yum is available only to fill dependencies and shouldn't be used directly? What are people's thoughts on this -- especially those that use RHEL? Is it confusing to have yum if RHEL can't use it to do system updates?
I'd like to get this discussed here on the list so that we can make a decision about it at the next EPEL meeting if needed.
Thanks, Jeff
On Mon, 6 Aug 2007, Jeff Sheltren wrote:
On Jul 27, 2007, at 8:48 AM, Michael DeHaan wrote:
I haven't looked at these packages yet, but I'm really glad to see this work being done. I mentioned this on #epel a few days ago -- lots of folks will be looking for yum to be there.
The selfish reason for me to want it is that Cobbler (http://cobbler.et.redhat.com) uses it for repository management and is otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not so selfish reason is tons of RHEL4 users are already using yum for various things (including maintaining their own repositories of lots of stuff, including, sometimes, updates) and it would be nice if they could get their yum from EPEL and use yum with EPEL if they wanted.
The second issue was that RHEL 4 users can't use yum for system updates. Do we need to provide a wiki page explaining to RHEL users that yum is available only to fill dependencies and shouldn't be used directly? What are people's thoughts on this -- especially those that use RHEL? Is it confusing to have yum if RHEL can't use it to do system updates?
They can, with a tool called mrepo. mrepo can mirror repositories and RHN channels and provide update packages for different RHEL versions, channels and archs to an internal network (or the local system).
For a single system this may be overkill (wrt. harddisk space) but for a small network of RHEL (or CentOS) systems, the ability to mirror, manage and browse repositories is a joy.
Besides, in no production environment do you want to enable a repository like RPMforge or EPEL (or even RHEL) without first testing these packages. So you need a way to move packages from a mirrored repository to a staging/testing/production repository on a case to case basis.
mrepo allows you to do that with little configuration.
You can find mrepo at:
http://dag.wieers.com/home-made/mrepo/
(there is work underway to also support NLD/SLES automatically, which is currently only mildly supported or requires manual steps)
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Mon, 2007-08-06 at 16:21 +0200, Dag Wieers wrote:
On Mon, 6 Aug 2007, Jeff Sheltren wrote:
On Jul 27, 2007, at 8:48 AM, Michael DeHaan wrote:
I haven't looked at these packages yet, but I'm really glad to see this work being done. I mentioned this on #epel a few days ago -- lots of folks will be looking for yum to be there.
The selfish reason for me to want it is that Cobbler (http://cobbler.et.redhat.com) uses it for repository management and is otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not so selfish reason is tons of RHEL4 users are already using yum for various things (including maintaining their own repositories of lots of stuff, including, sometimes, updates) and it would be nice if they could get their yum from EPEL and use yum with EPEL if they wanted.
The second issue was that RHEL 4 users can't use yum for system updates. Do we need to provide a wiki page explaining to RHEL users that yum is available only to fill dependencies and shouldn't be used directly? What are people's thoughts on this -- especially those that use RHEL? Is it confusing to have yum if RHEL can't use it to do system updates?
They can, with a tool called mrepo. mrepo can mirror repositories and RHN channels and provide update packages for different RHEL versions, channels and archs to an internal network (or the local system).
They can, and they do. We currently use mrepo to mirror RHEL4 and RHEL5 repositories of interest from our campus RHN satellite server. We use yum to pull in our local, home-grown repos, as well as the RHN updates. Furthermore, up2date seems to coexist just fine with yum.
rob.
On 06.08.2007 16:04, Jeff Sheltren wrote:
On Jul 27, 2007, at 8:48 AM, Michael DeHaan wrote:
I haven't looked at these packages yet, but I'm really glad to see this work being done. I mentioned this on #epel a few days ago -- lots of folks will be looking for yum to be there.
The selfish reason for me to want it is that Cobbler (http:// cobbler.et.redhat.com) uses it for repository management and is otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not so selfish reason is tons of RHEL4 users are already using yum for various things (including maintaining their own repositories of lots of stuff, including, sometimes, updates) and it would be nice if they could get their yum from EPEL and use yum with EPEL if they wanted.
During the EPEL meeting on July 25 -- log here: https://www.redhat.com/archives/epel-devel-list/2007-July/msg00225.html There was some discussion about problems including yum in EPEL.
The first issue was that these packages don't mess up CentOS users. Since these packages all have a lower release than those found in CentOS, that should not be a problem since they should never get installed in the first place.
+1
The second issue was that RHEL 4 users can't use yum for system updates.
Or install packages from EPEL that require deps from RHEL4, as long as they don't set up their own RHEL-repo (see the other mails from dag on this topic).
Do we need to provide a wiki page explaining to RHEL users that yum is available only to fill dependencies and shouldn't be used directly? What are people's thoughts on this -- especially those that use RHEL? Is it confusing to have yum if RHEL can't use it to do system updates?
My preferred solution: add a patch that makes yum *on RHEL only* display a warning like "you should use up2date on RHEL4 to install packages from EPEL or update RHEL itself" and add a config option to disabled that warning for those that use mrepo to set up a RHEL-updates repo.
I'd like to get this discussed here on the list
List is preferred for such discussions, as it's IMHO to time consuming to discuss all details in a IRC meeting if they havened been discussed on the list yet -- if they have and no consensus could be found then it's in my experience easier to come to an agreement in a IRC meeting.
so that we can make a decision about it at the next EPEL meeting if needed.
+1 -- it's still on the schedule.
Cu knurd
Creating a repo for users of RHEL is a great solution that allows for YUM usage on RHEL, however it doesn't solve the exact problem with the package of YUM on RHEL.
The issue is the package itself. EPEL has no way of shipping a 100% working version of YUM on RHEL 4. So, I still say we place something in yum.conf to let the RHEL user know that YUM won't "just work" until they help it out some.
stahnma
On Aug 6, 2007, at 12:01 PM, Michael Stahnke wrote:
The issue is the package itself. EPEL has no way of shipping a 100% working version of YUM on RHEL 4. So, I still say we place something in yum.conf to let the RHEL user know that YUM won't "just work" until they help it out some.
I'm pretty happy with doing something like this. Of course, it'll be pretty clear that it doesn't work when they try to use it and it doesn't work ;)
Maybe a small blurb on the wiki explaining yum within EPEL would help as well?
-Jeff
Jeff Sheltren wrote:
On Aug 6, 2007, at 12:01 PM, Michael Stahnke wrote:
The issue is the package itself. EPEL has no way of shipping a 100% working version of YUM on RHEL 4. So, I still say we place something in yum.conf to let the RHEL user know that YUM won't "just work" until they help it out some.
I'm pretty happy with doing something like this. Of course, it'll be pretty clear that it doesn't work when they try to use it and it doesn't work ;)
Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if that works?
Rahul
Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if that works?
I use yum/rhn on RHEL 5 lots. It works most of the time. RHN+YUM is still having a few growing pains, but it's getting better. That configuration is handled more via the plugin and RHN bootstrap than by anything EPEL is currently able to provide.
stahnma
Michael Stahnke wrote:
Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if that works?
I use yum/rhn on RHEL 5 lots. It works most of the time. RHN+YUM is still having a few growing pains, but it's getting better. That configuration is handled more via the plugin and RHN bootstrap than by anything EPEL is currently able to provide.
The point is that if you are pushing yum into EPEL and yum RHN plugin works in EPEL 4, you can as well as take it from RHEL 5 and push the plugin to the EPEL 4 branch and things will work more out of the box.
Rahul
On 8/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Michael Stahnke wrote:
Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if that works?
I use yum/rhn on RHEL 5 lots. It works most of the time. RHN+YUM is still having a few growing pains, but it's getting better. That configuration is handled more via the plugin and RHN bootstrap than by anything EPEL is currently able to provide.
The point is that if you are pushing yum into EPEL and yum RHN plugin works in EPEL 4, you can as well as take it from RHEL 5 and push the plugin to the EPEL 4 branch and things will work more out of the box.
What RHN server do propose we register them with?
Rahul
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Michael Stahnke wrote:
On 8/7/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Michael Stahnke wrote:
Has anyone tried out yum RHN plugin from RHEL 5 on RHEL 4 and checked if that works?
I use yum/rhn on RHEL 5 lots. It works most of the time. RHN+YUM is still having a few growing pains, but it's getting better. That configuration is handled more via the plugin and RHN bootstrap than by anything EPEL is currently able to provide.
The point is that if you are pushing yum into EPEL and yum RHN plugin works in EPEL 4, you can as well as take it from RHEL 5 and push the plugin to the EPEL 4 branch and things will work more out of the box.
What RHN server do propose we register them with?
The existing RHEL ones. The idea behind is it that yum can then be used as a single tool for both RHEL base repository and EPEL.
Rahul
epel-devel@lists.fedoraproject.org
-
Dag Wieers -
Jeff Sheltren -
Johnny Hughes -
Manuel Wolfshant -
Michael DeHaan -
Michael Stahnke -
Patrice Dumas -
Rahul Sundaram -
Rob Myers -
Steven Pritchard -
Thorsten Leemhuis