On Thu, 2003-11-13 at 16:49, Jeremy Katz wrote: > The group interface is absolutely *crucial* to the usability of the > tool. Having 1500 packages ungrouped in any sort of sane, scalable > mechanism (and without regard for trimming to just leaf packages instead > of listing everything libgal that's a dependency of something ;) is a > nitemare. Is the intent to move away from comps.xml towards the package determining where it should go in the package heirarchy by itself via its metaData. In a closed scenario such as fedora core the comps.xml probably works fine. But, in a open scenario such as core + extras + 3rd party the comps.xml approach seems to fall apart. > To be honest, trying to kludge either into working is going to lead to a > complete lack of maintainability, IMHO. Realistically, both the yum > side of things and the redhat-config-packages side of things need to > move towards using the New Improved RPM Metadata that's being > discussed/developed. Is the intent to retain backwards compatablity with cdrom/ftp/http rpm sources or will these all become yum repos on different mediums? > Brent and I sat down and cleaned up/refined the design spec we did six > months ago for redhat-config-packages and tried to also update it a bit > to take into account some of the changes since then. Hopefully we'll > finish getting this written up and sent out by the beginning of next > week. I'm looking forward to your specs. In the meantime i'll continue hacking on the existing -packages code. By do so, I am finding things the need to be passed up stream to the yum folks. 1. Ability to pass progress messages back to the gui not just the terminal. 2. Exception Handling which can be passed back the gui. 3. No sys.exits() evil 3. Currently, passing takeAction commands to yum are of the format [action, (packageNameList)] for GUI interaction a format of [action: filename, action:filename] is probably better. > The short summary is that I think that starting with just the existing > code is going to make things far more painful than they should be. > Stepping back and looking at the big picture and going from there > instead of trying to hijack in things that were never intended to exist > is the wrong approach. Also, I would like to move things to where we > don't have four different tools for the same basic thing and can have it > as consolidated into one tool as much as possible. I'd far rather get > things done right, even if it takes longer, than continue the hacks like > I've been doing thus far :) Which four tools would you like to wrap together -packages, up2date, the packages install portion of annaconda... >From a managing the branches point of view, would it make sense to focus effort on -packages? Thanks Dave Farning