Hi
Yup, its that question again : do we want to leave, but patch-to-non-functional the rhn and subscription-manager tools in the distro. I know its useful to some projects to leave in, but do they care ?
- KB
-----Original Message----- From: Karanbir Singh Sent: Wednesday, June 18, 2014 9:59
Hi
Yup, its that question again : do we want to leave, but patch-to-non-functional the rhn and subscription-manager tools in the distro. I know its useful to some projects to leave in, but do they care ?
How, if any, does this impact the "most proper" way of converting from CentOS to RHEL on a live system.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00.
On 18/06/14 16:09, Jason Pyeron wrote:
-----Original Message----- From: Karanbir Singh Sent: Wednesday, June 18, 2014 9:59
Hi
Yup, its that question again : do we want to leave, but patch-to-non-functional the rhn and subscription-manager tools in the distro. I know its useful to some projects to leave in, but do they care ?
How, if any, does this impact the "most proper" way of converting from CentOS to RHEL on a live system.
Well, converting a CentOS to RHEL is actually unsupported upstream, so you'd have to reinstall it (even if technically, that would be doable). Some people are still probably interested in having those packages "ready-to-be-consumed" when they have an internal Spacewalk server (Satellite would not work, as not support for CentOS machines either)
I'd be interested in hearing people willing to have those packages available in the distro
On 06/18/2014 03:09 PM, Jason Pyeron wrote:
How, if any, does this impact the "most proper" way of converting from CentOS to RHEL on a live system.
how has this worked in the past? we dont ship rhn tools in CentOS-5/6 either.
On 06/18/2014 09:30 AM, Karanbir Singh wrote:
On 06/18/2014 03:09 PM, Jason Pyeron wrote:
How, if any, does this impact the "most proper" way of converting from CentOS to RHEL on a live system.
how has this worked in the past? we dont ship rhn tools in CentOS-5/6 either.
My opinion on this is that we should take them out of the distro and IF someone like Spacewalk needs them then they can push modified versions as part of a SIG. We could push a version that works with Spacewalk if we want .. but it might be better if they do it as then they can configure them the right way, etc.
I mean, we CAN include them, but we haven't in the past, and people still use spacewalk.
On 06/18/2014 11:17 AM, Johnny Hughes wrote:
On 06/18/2014 09:30 AM, Karanbir Singh wrote:
On 06/18/2014 03:09 PM, Jason Pyeron wrote:
How, if any, does this impact the "most proper" way of converting from CentOS to RHEL on a live system.
how has this worked in the past? we dont ship rhn tools in CentOS-5/6 either.
My opinion on this is that we should take them out of the distro and IF someone like Spacewalk needs them then they can push modified versions as part of a SIG. We could push a version that works with Spacewalk if we want .. but it might be better if they do it as then they can configure them the right way, etc.
I mean, we CAN include them, but we haven't in the past, and people still use spacewalk.
Upstream spacewalk has:
http://spacewalk.redhat.com/yum/2.1-client/RHEL/6/x86_64/
containing the necessary bits for spacewalk integration on 5 and 6.
Pat
On 06/18/2014 04:30 PM, Karanbir Singh wrote:
how has this worked in the past? we dont ship rhn tools in CentOS-5/6 either.
In past rhn-client-tools was not shipped, because they were by default on and pointed to rhn.redhat.com And there were no Spacewalk project at that time. Therefore no useful for CentOS
All three reason are no longer true and default url is: enter.your.server.url.here and disabled by default.
In past I tried to get back Spacewalk version of rhn-client-tools to CentOS-5/6, but I have been told to keep it as is. And that you will get it in CentOS 7.
I see no reason why not include rhn-client-tools in RHEL-7. And I see no reason why patch it.
I could not speak for RHSM as I no longer follow it.
On 06/18/2014 03:59 PM, Karanbir Singh wrote:
Hi
Yup, its that question again : do we want to leave, but patch-to-non-functional the rhn and subscription-manager tools in the distro. I know its useful to some projects to leave in, but do they care ?
i don't see any reason. what's more it's running if installed and it's installed if included in the repo. so do not add!
On 06/18/2014 03:51 PM, Farkas Levente wrote:
On 06/18/2014 03:59 PM, Karanbir Singh wrote:
Hi
Yup, its that question again : do we want to leave, but patch-to-non-functional the rhn and subscription-manager tools in the distro. I know its useful to some projects to leave in, but do they care ?
i don't see any reason. what's more it's running if installed and it's installed if included in the repo. so do not add!
I guess the spacewalk/foreman/katello folks might have an opinion, mostly wondering where they are placed these days.
On Wed, Jun 18, 2014 at 4:51 PM, Farkas Levente lfarkas@lfarkas.org wrote:
On 06/18/2014 03:59 PM, Karanbir Singh wrote:
Hi
Yup, its that question again : do we want to leave, but patch-to-non-functional the rhn and subscription-manager tools in the distro. I know its useful to some projects to leave in, but do they care
?
i don't see any reason. what's more it's running if installed and it's installed if included in the repo. so do not add!
but at the same time as the c7 will be released it'd be very important to add to the c6 repo these packages: preupgrade-assistant preupgrade-assistant-contents preupgrade-assistant-ui redhat-upgrade-tool since they needed for in place upgrade. but these may depend on the above and also the c7 repo url. so imho these packages should have to added to c6 repo asap.
ps. i've never been able to run preupgrade-assistant to produce usable output. it's always runs (for a long time) but the result table was always empty.
pss. be careful it's version change very quickly
Hello Karanbir Singh,
On Wed, Jun 18, 2014 at 02:59:18PM +0100, Karanbir Singh wrote:
Hi
Yup, its that question again : do we want to leave, but patch-to-non-functional the rhn and subscription-manager tools in the distro. I know its useful to some projects to leave in, but do they care ?
Even epel-release depends on rhn files for CentOS7 at the moment: https://bugzilla.redhat.com/show_bug.cgi?id=1093918
Seems to be the same bug again as was done a few years ago for CentOS-6. :-)
best regards,
Florian La Roche
On 06/18/2014 03:56 PM, Florian La Roche wrote:
Hello Karanbir Singh,
On Wed, Jun 18, 2014 at 02:59:18PM +0100, Karanbir Singh wrote:
Hi
Yup, its that question again : do we want to leave, but patch-to-non-functional the rhn and subscription-manager tools in the distro. I know its useful to some projects to leave in, but do they care ?
Even epel-release depends on rhn files for CentOS7 at the moment: https://bugzilla.redhat.com/show_bug.cgi?id=1093918
what does the rhn/sources file contain ? can we mock/stub that from centos-release ? ( is there a need to.. )
On 06/18/2014 11:30 AM, Karanbir Singh wrote:
On 06/18/2014 03:56 PM, Florian La Roche wrote:
Hello Karanbir Singh,
On Wed, Jun 18, 2014 at 02:59:18PM +0100, Karanbir Singh wrote:
Hi
Yup, its that question again : do we want to leave, but patch-to-non-functional the rhn and subscription-manager tools in the distro. I know its useful to some projects to leave in, but do they care ?
Even epel-release depends on rhn files for CentOS7 at the moment: https://bugzilla.redhat.com/show_bug.cgi?id=1093918
what does the rhn/sources file contain ? can we mock/stub that from centos-release ? ( is there a need to.. )
There's also the issue of the rhn integration into libreport/abrt (RPM: libreport-plugin-rhtsupport). Whatever solution goes here should probably be applied to that pkg as well - it's a very similar situation. Simply dropping it means modifying the dependencies in a bunch of packages which try to include it, whereas the option is modifying to remove branding - which seems useless because there is just no point.
-
David Mansfield -
Fabian Arrotin -
Farkas Levente -
Florian La Roche -
Jason Pyeron -
Johnny Hughes -
Karanbir Singh -
Miroslav Suchý -
Pat Riehecky