Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Tue, Sep 08, 2009 at 12:06:46PM -0500, Dennis Gilmore wrote: On Tuesday 08 September 2009 11:52:43 am Brandon Perkins wrote: As I understand it, the main concern that Miroslav was having in this case was avoiding installing new versions of packages from Spacewalk that are also shipped with RHEL or RHN Client Tools. Basically, wanting to avoid someone accidentally upgrading a Red Hat shipped package with a Spacewalk package and making support a little more cumbersome. Making sure we dont ship those packages I think is the right answer. There a few we need to not ship as fedora/EPEL ships them. I will work on blocking the packages that we should not ship. Hello Dennis, has this been done and is the client repository available for use somewhere? -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
2009/9/8 Dennis Gilmore den...@ausil.us: On Friday 04 September 2009 07:33:36 am Miroslav Suchý wrote: Today, we have both Spacewalk (and proxy) packages together in one repo with client packages. If somebody will install Spacewalk on RHEL he will get as side effect all those client packages (rhnlib, yum-rhn-plugin, rhn-client-tools), which will get him to unsupported state. I'm not sure if this is what we wanted. In fast, we probably do not want this. I suggest to split yum repo to two parts. One is Spacewalk and Proxy. Second is client tools. Do you agree? Do you disagree? Any comments? We cant easily do this. Without creating a maintenance headache for ourselves. mash grabs all the packages from a koji tag and puts them into a repo. taking into account inheritance. To implement this we would need to setup additional tags inheriting from the build tags and then we would need to block all of the packages we dont want in the mashed repos. if any sub rpms are split across repos we cant do that. Keeping in mind we should be getting everything into Fedora/EPEL so that the koji we use can go away remember its only a temporary setup. This is alot of extra work for little gain. the blocking of packages would need to happen on each and every version bump of spacewalk. our best bet is likely to block the packages that are shipped in RHEL so we do not build our own version and make sure that CentOS ships them. and continue with our single repo. It sounds like a nightmare on the koji side. So what is it that we're trying to resolve with this change? I know from a user's point of view it makes sense to see a client and a server repo. But what pain is really being caused with the current setup? ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Tuesday 08 September 2009 11:52:43 am Brandon Perkins wrote: Jesus M. Rodriguez wrote: 2009/9/8 Dennis Gilmore den...@ausil.us: On Friday 04 September 2009 07:33:36 am Miroslav Suchý wrote: Today, we have both Spacewalk (and proxy) packages together in one repo with client packages. If somebody will install Spacewalk on RHEL he will get as side effect all those client packages (rhnlib, yum-rhn-plugin, rhn-client-tools), which will get him to unsupported state. I'm not sure if this is what we wanted. In fast, we probably do not want this. I suggest to split yum repo to two parts. One is Spacewalk and Proxy. Second is client tools. Do you agree? Do you disagree? Any comments? We cant easily do this. Without creating a maintenance headache for ourselves. mash grabs all the packages from a koji tag and puts them into a repo. taking into account inheritance. To implement this we would need to setup additional tags inheriting from the build tags and then we would need to block all of the packages we dont want in the mashed repos. if any sub rpms are split across repos we cant do that. Keeping in mind we should be getting everything into Fedora/EPEL so that the koji we use can go away remember its only a temporary setup. This is alot of extra work for little gain. the blocking of packages would need to happen on each and every version bump of spacewalk. our best bet is likely to block the packages that are shipped in RHEL so we do not build our own version and make sure that CentOS ships them. and continue with our single repo. It sounds like a nightmare on the koji side. So what is it that we're trying to resolve with this change? I know from a user's point of view it makes sense to see a client and a server repo. But what pain is really being caused with the current setup? As I understand it, the main concern that Miroslav was having in this case was avoiding installing new versions of packages from Spacewalk that are also shipped with RHEL or RHN Client Tools. Basically, wanting to avoid someone accidentally upgrading a Red Hat shipped package with a Spacewalk package and making support a little more cumbersome. Making sure we dont ship those packages I think is the right answer. There a few we need to not ship as fedora/EPEL ships them. I will work on blocking the packages that we should not ship. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Friday 04 September 2009 07:33:36 am Miroslav Suchý wrote: Today, we have both Spacewalk (and proxy) packages together in one repo with client packages. If somebody will install Spacewalk on RHEL he will get as side effect all those client packages (rhnlib, yum-rhn-plugin, rhn-client-tools), which will get him to unsupported state. I'm not sure if this is what we wanted. In fast, we probably do not want this. I suggest to split yum repo to two parts. One is Spacewalk and Proxy. Second is client tools. Do you agree? Do you disagree? Any comments? We cant easily do this. Without creating a maintenance headache for ourselves. mash grabs all the packages from a koji tag and puts them into a repo. taking into account inheritance. To implement this we would need to setup additional tags inheriting from the build tags and then we would need to block all of the packages we dont want in the mashed repos. if any sub rpms are split across repos we cant do that. Keeping in mind we should be getting everything into Fedora/EPEL so that the koji we use can go away remember its only a temporary setup. This is alot of extra work for little gain. the blocking of packages would need to happen on each and every version bump of spacewalk. our best bet is likely to block the packages that are shipped in RHEL so we do not build our own version and make sure that CentOS ships them. and continue with our single repo. Dennis signature.asc Description: This is a digitally signed message part. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Tue, Sep 08, 2009 at 10:41:18AM -0500, Dennis Gilmore wrote: We cant easily do this. Without creating a maintenance headache for ourselves. mash grabs all the packages from a koji tag and puts them into a repo. taking into account inheritance. To implement this we would need to setup additional tags inheriting from the build tags and then we would need to block all of the packages we dont want in the mashed repos. if any sub rpms are split across repos we cant do that. Keeping in mind we should be getting everything into Fedora/EPEL so that the koji we use can go away remember its only a temporary setup. This is alot of extra work for little gain. the blocking of packages would need to happen on each and every version bump of spacewalk. our best bet is likely to block the packages that are shipped in RHEL so we do not build our own version and make sure that CentOS ships them. and continue with our single repo. If mash cannot achieve what we need to achieve, perhaps we need to work with the upstream to add the features we need there, or consider using other tools (pungi?), or write our own. -- Jan Pazdziora | adelton at #satellite*, #brno Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
On Mon, Sep 07, 2009 at 08:42:23AM +0200, Miroslav Suchý wrote: Jesus M. Rodriguez wrote: yum/0.7/proxy yum/0.7/server IMO this does not bring any benefit. A lot of packages are common. If you install proxy, yum will not install Spacewalk server packages and vice versa. Right. On the other hand, the split will make it easier to repo sync just the proxy repo to your Spacewalk server. Plus, it's what we do with Satellite and RHN Proxy as well. But if you install Proxy or Spacewalk, yum will install new client tools. Well, that's why Jesus had that yum/0.7/client there as well. -- Jan Pazdziora Senior Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
Miroslav Suchý wrote: I suggest to split yum repo to two parts. One is Spacewalk and Proxy. Second is client tools. Do you agree? Do you disagree? Any comments? OK. No objections heard. Jesus can you give me contact on RH person responsible of http://spacewalk.redhat.com/yum/ ? If I understand the process I had to prepare the content in svn/branches/spacewalk_web/ once done, send ticket to And that is all. Dennis, can you do the necessary steps (in mash?) to generate two yum repos? Client packages should be: rhcfg* rhn-custom-info osad rhn-applet-actions rhn-custom-info rhn-kickstart* rhn-virtualization* spacewalk-koan rhnlib rhnmd rhnsd rhn-check rhn-setup yum-rhn-plugin koan spacewalk-certs-tools spacewalk-koan Everything else should stay in the yum repo as it is now. From Brandon's list I rejected: jabberpy perl-IO-stringy rhnpush spacewalk-proxy-installer spacewalk-ssl-cert-check spacewalk-ssl-cert-check They are needed for Spacewalk server/Proxy and with older releases it may be unable to install or run. So we should have them server yum repo and not in client repo. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
Jan Pazdziora wrote: On Mon, Sep 07, 2009 at 08:42:23AM +0200, Miroslav Suchý wrote: Jesus M. Rodriguez wrote: yum/0.7/proxy yum/0.7/server IMO this does not bring any benefit. A lot of packages are common. If you install proxy, yum will not install Spacewalk server packages and vice versa. Right. On the other hand, the split will make it easier to repo sync just the proxy repo to your Spacewalk server. Plus, it's what we do with Satellite and RHN Proxy as well. But we do it, because we take money for each of them. In Spacewalk it is in one pack for one price :) But if you install Proxy or Spacewalk, yum will install new client tools. Well, that's why Jesus had that yum/0.7/client there as well. That is why I did not argued about client. I'm only against server/proxy split. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
Brandon Perkins wrote: I completely agree, I would just also add rhnsd to the list: rhn-client-tools rhnlib rhnsd yum-rhn-plugin This looks like the authoritative list when I looked through Koji. There is for sure others: rhcfg* rhn-custom-info osad I did not investigate it. Neither for first time nor now. Looking to client/* others package to consider are: action-rpms (rhn-applet-actions) rhncustominfo (rhn-custom-info) rhn-kickstart (all packages from this) rhn-virtualization (all packages from this) spacewalk-koan -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miroslav Suchý wrote: Brandon Perkins wrote: I completely agree, I would just also add rhnsd to the list: rhn-client-tools rhnlib rhnsd yum-rhn-plugin This looks like the authoritative list when I looked through Koji. There is for sure others: rhcfg* rhn-custom-info osad I did not investigate it. Neither for first time nor now. Looking to client/* others package to consider are: action-rpms (rhn-applet-actions) rhncustominfo (rhn-custom-info) rhn-kickstart (all packages from this) rhn-virtualization (all packages from this) spacewalk-koan Right, my first list was just RHEL parent content. If we think about RHN Tools child content as well, the list goes up to: jabberpy osad rhncfg rhn-client-tools rhn-custom-info rhn-kickstart rhnlib rhnmd rhnsd rhn-virtualization yum-rhn-plugin Regardless, I still think splitting is the right thing to do. Thanks. Brandon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFKoUlUhwQhj8l1t/cRAm4OAJsGi4Okq/FutacdSbh/Kk1tGU4KBwCgr8m5 tC96I6COuK+VCf6UIJMO7KQ= =6Ajl -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brandon Perkins wrote: Miroslav Suchý wrote: Brandon Perkins wrote: I completely agree, I would just also add rhnsd to the list: rhn-client-tools rhnlib rhnsd yum-rhn-plugin This looks like the authoritative list when I looked through Koji. There is for sure others: rhcfg* rhn-custom-info osad I did not investigate it. Neither for first time nor now. Looking to client/* others package to consider are: action-rpms (rhn-applet-actions) rhncustominfo (rhn-custom-info) rhn-kickstart (all packages from this) rhn-virtualization (all packages from this) spacewalk-koan Right, my first list was just RHEL parent content. If we think about RHN Tools child content as well, the list goes up to: jabberpy osad rhncfg rhn-client-tools rhn-custom-info rhn-kickstart rhnlib rhnmd rhnsd rhn-virtualization yum-rhn-plugin Regardless, I still think splitting is the right thing to do. Thanks. Brandon And I now realize I'm missing: koan perl-IO-stringy rhnpush spacewalk-certs-tools spacewalk-koan spacewalk-proxy-installer spacewalk-ssl-cert-check spacewalk-utils But, between those two lists, that *should* be everything that would need to be split out. Thanks. Brandon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFKoUy0hwQhj8l1t/cRAp7BAJ4zqIhqDCbRv7E+HY9AWQaXBSwwtACgkw7z Ri1rSGzv29yW3F7TCnvW+EM= =SDRL -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Split of spacewalk yum repo?
2009/9/4 Miroslav Suchý msu...@redhat.com: Today, we have both Spacewalk (and proxy) packages together in one repo with client packages. If somebody will install Spacewalk on RHEL he will get as side effect all those client packages (rhnlib, yum-rhn-plugin, rhn-client-tools), which will get him to unsupported state. I'm not sure if this is what we wanted. In fast, we probably do not want this. I suggest to split yum repo to two parts. One is Spacewalk and Proxy. Second is client tools. Do you agree? Do you disagree? Any comments? How about we do the following: yum/0.7/client yum/0.7/proxy yum/0.7/server and under each of those we add RHEL, Fedora, etc. I will let others decide what goes in the client proxy :) jesus ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
