On Thu, Apr 04, 2013 at 05:44:09PM +0200, Johannes Renner wrote: > > > > 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.
Hmm, I wonder if the current logic is actually correct. It feel that a kickstartable channel (for the purpose of creating kickstart profile, for example) would be channel that has at least one kickstartable tree, or channel cloned from one that has the tree. Which is not a logic I can see in Channel.kickstartableChannels. If we changed the logic this way, that would work for SUSE as well, right? I'd much prefer to do it this way than hardcoding yet another name of package to the code base. Of course, creating new distribution should basically be allowed for any parent channel, it would seem. > 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. Fair enough. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
