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
