On 04/04/2013 04:31 PM, Jan Pazdziora wrote: > On Thu, Apr 04, 2013 at 03:37:07PM +0200, Johannes Renner wrote: >> On 03/22/2013 02:55 PM, Michael Calmer wrote: >>> Hi, >>> >>> please do not apply these patches. I found out, that it is not correct. >>> It removes the channels at more places than needed. >> >> I guess the initial patch would be fine, as long as we add some additional >> small fixes on top. Here is another single patch containing everything. >> >> Basically what we are doing is to distinguish between "kickstartable" and >> "autoinstallable" channels. It would be really helpful though to get some >> feedback from you about using the anaconda package as a filter criteria. > > Can you elaborate on the purpose of this change in general? The current > code uses the > > Channel.kickstartableChannels > > query everywhere (via getKickstartableChannels). The patch seems to > change the semantics for all getKickstartableChannels(org) > invocations. What is the purpose? Why should all the other invocations > start to care about anaconda?
Sure, the problem is with the "create a new kickstart profile" wizard that can be found if you navigate to "Systems" -> "Kickstart". The first step of this wizard lets you decide on a base channel for the profile, where the above query is used to determine the candidates. SUSE channels should *not* be listed here, since it is not possible to have a kickstart profile with a SUSE base channel. This leads to the conclusion that only those channels should be listed, that actually support kickstarts (-> "kickstartable"). As far as we know, Anaconda is the package that should make a channel kickstartable, since the whole kickstarting seems to be implemented in there, right? It's different though with the kickstart "distributions". If you go there and click "create new distribution", you want to have those SUSE channels listed a well. Distributions can be used with kickstart *as well as* with autoyast profiles! That's why we would need to return the unfiltered list here. We named this superset "autoinstallable" channels. All other invocations should be expecting "kickstartable" channels only. > Also, I'm not sure about the use of > ChannelManager.listLatestPackagesEqual here -- we don't care about > the latest at all, do we? The thing is happy about any package it > finds so the best way is to just check for existence, without any > newest computation needed. I don't think there is actually logic implemented that would produce any kind of overhead. It's all in the database as you can see if you look at the used query (in Channel_queries.xml) "latest_package_equal". Also I saw in another place that looking up a package was done like this, so this method appeared to be easier than anything else. It can be changed of course, if you want. I agree that we don't need the latest version of a package, but it looks like as soon as there is a record in the table "rhnChannelNewestPackage", we can assume this package is contained in the channel. Regards, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
