I just read: http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.0#head-c667a3d0dc5a41aff... And I wonder why has been: rhnlib rhn-check rhn-client-tools rhnsd rhn-setup rhn-setup-gnome yum-rhn-plugin removed from CentOS 6?
We discussed it more than year ago: http://lists.centos.org/pipermail/centos-devel/2010-January/005307.html http://lists.centos.org/pipermail/centos-devel/2010-February/005402.html and the conclusion was that we will leave CentOS 5 as is (i.e. do not add there this packages) but in CentOS 6 this packages will not be removed. So I'm quite surprised that they are removed? Can somebody share with me the details why it has been removed?
Hi Miroslav,
On 07/11/2011 10:36 AM, Miroslav Suchý wrote:
and the conclusion was that we will leave CentOS 5 as is (i.e. do not add there this packages) but in CentOS 6 this packages will not be removed.
I tried to raise this question again, and the general feeling that everyone got was : spacewalk users tend to setup their own custom repo's and therefore dont rely on the *rhn* code in the distro. Also spacewalk users are mostly using newer code than whats in the distro, so leaving those packages in does not help.
If there was to be some sort of a clear reason as to why these packages should be included, I personally dont have any objections to re-introducing them ( we can do it into Extras/ for 6.0 and reinstate them into the 6.1/os distro ). So if we can get some level of agreement with the community at large that these rpms help, we can look at doing the work.
It would also help if someone was to do a code audit and make sure these *rhn* rpms:
- have no TM issues
- carry no Red Hat hosted dependancies
- have nothing that might indicate to a user that they are running RHEL or a related product
- Have no by-default action that access or tries to access a .redhat.com hosted resource
And finally : report those on the bugs.c.o instance ( so open a report at bugs.c.o against each srpm name, and either indicate a change is needed or state that no-change-is-needed )
Regards,
- KB
Having the packages in centos would allow us to use the same kickstarts as we use on tuv 6.0 deployments. The spacewalk-client repos are a bit unstable also so it is nice to have the vendor supported version of the tools on the base os. It usually works against most versions of the server without bothering to install the spacewalk-client repos. Also last I checked the spacewalk-client repo brings in dependencies on epel, so then we have to drag the that repo into our kickstarts as well.
Thanks, Trent
On Mon, Jul 11, 2011 at 10:36 AM, Karanbir Singh mail-lists@karan.org wrote:
Hi Miroslav,
On 07/11/2011 10:36 AM, Miroslav Suchý wrote:
and the conclusion was that we will leave CentOS 5 as is (i.e. do not add there this packages) but in CentOS 6 this packages will not be removed.
I tried to raise this question again, and the general feeling that everyone got was : spacewalk users tend to setup their own custom repo's and therefore dont rely on the *rhn* code in the distro. Also spacewalk users are mostly using newer code than whats in the distro, so leaving those packages in does not help.
If there was to be some sort of a clear reason as to why these packages should be included, I personally dont have any objections to re-introducing them ( we can do it into Extras/ for 6.0 and reinstate them into the 6.1/os distro ). So if we can get some level of agreement with the community at large that these rpms help, we can look at doing the work.
It would also help if someone was to do a code audit and make sure these *rhn* rpms:
have no TM issues
carry no Red Hat hosted dependancies
have nothing that might indicate to a user that they are running RHEL
or a related product
- Have no by-default action that access or tries to access a .redhat.com
hosted resource
And finally : report those on the bugs.c.o instance ( so open a report at bugs.c.o against each srpm name, and either indicate a change is needed or state that no-change-is-needed )
Regards,
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hi Guys,
On 07/11/2011 04:51 PM, Trent Johnson wrote:
Having the packages in centos would allow us to use the same kickstarts as we use on tuv 6.0 deployments.
Could you please file an issue report about these packages at bugs.centos.org/ and mark it against 6.1 QA
Otherwise we might just lose the conversation in the lists
- KB
Could you please file an issue report about these packages at bugs.centos.org/ and mark it against 6.1 QA
The question will be what URL to put in place for the satellite server.
A place holder of HTTP://your.satellite.server.here would probably be sensible.
I still do question the point of this given that in kickstart you would still have to replace this and import the spacewalk certificate. If doing that much it is trivial to have a --repo line and a local copy of the 22 packages that make up the spacewalk client report either as a channel or a proper yum repo.
On 07/19/2011 08:00 AM, James Hogarth wrote:
doing that much it is trivial to have a --repo line and a local copy of the 22 packages that make up the spacewalk client report either as a channel or a proper yum repo.
I think part of the issue is that what repo would one point at in this manner ? if its the spacewalk tools, those are then not in sync with the rhn code in the distro.
Having this code in the distro seems to imply that a lot more functionality could be shared between RHEL and CentOS installs.
- KB
-
James Hogarth -
Karanbir Singh -
Miroslav Suchý -
Trent Johnson