On Sun, 2003-07-27 at 09:53, Jos Vos wrote: > Hi, > > After reading about Yum on the RHL beta mailing list and experimenting > with apt-rpm, I decided to try Yum. Here are my questions and > comments (I'm using RHL 9 as both the server- and client-platform, > using the yum-2.0-1 rpm found on the Yum web pages): > > - The man page of yum suggests that the -z flag will compress the > header info, but it seems that this always happens and that the > -z flag effectively is a no-op. > very true - it used to have meaning and I left it in place so people's scripts wouldn't bail out with a 'no option named -z' error. > - I want to force a priority sequence for my Yum servers, so that > packages of a higher prio server do *always* take precedence over > packages of a lower prio server, regardless the version numbers. > I assumed "pkgpolicy=last" would do this, but it seems to work only > partly: when a new package is installed, it indeed takes the one > from the higher prio server, regardless how the version compare. > But if a package is already installed, it doesn't upgrade (in my > case this means downgrade) to the version of the higher prio server. > > I can't really understand this policy, as in this way client > systems using the same Yum servers end up with different package > sets (versions), dependent on the time a package was installed. > This is an unwanted behaviour, IMHO, as systems like Yum should > ensure a uniform set of client systems (except for what packages > are installed, but this can be tweaked with special packages). downgrading is not as easy as it appears and dealing with downgrades in operation will take some effort. > - Running "yum install ..." sometimes results in a segmentation fault, > but doing it again works fine then. Sometimes it also hangs, but > this is a known problem with rpm (rm -f /var/lib/__db* ...). You should look HARD at the system in question about the segfaults. I haven't gotten ANY segfaults from yum that weren't related to hardware going funky. > - Kernel "upgrades": Yum installs the kernel (i.s.o. upgrading it), > which is fine, but this seems to be a built-in feature. Can I also > do this with other packages (like the "allow-duplicated" in apt-rpm)? no - you cannot do this at this time. It is planned to have a list of pkgs which are marked as 'install-only'. allow-duplicated is bizarre in my opinion - allowing dupes is obvious - but knowing when to install something instead of upgrade is not-so-obvious and therefore useful. > - Making the new kernel the default should be an option, I think. > See also the remark about scripting below, as I would like to see > this done in an external script or Python module, instead of > having this as built-in code. look at the todo list - it's on there - it's not a trivial abstraction to do in one cut. The trick is planning the features enough in advance to know what you're going to get. B/c once you setup the external scripting and what it passes on to the external scripts you're stuck with that api for a WHILE. So it's been on the 'thinking about' burner for a bit so I don't end up painting myself into a corner with some ridiculous interface to it. > - When I rename a server id in /etc/yum.conf, the old cache info > (with the old server id) never seems to be removed, not even > with "yum clean all". right -b/c at that point yum knows nothing about it. It's the only nice way to deal with multiple config files - so they don't tread on each other's cache. > - RFE: I would like to be able to run scripts before or after rpm > actions being done (like the LUA scripts can do in apt-rpm). > I know this is Python and it should be probably pretty easy to > add myself, but maybe this can be made a generic feature? > > In general, I like that the code being *much* smaller than apt-rpm > (why is this so extremely huge...) and more accessible (as it is > Python), but I think a few more features would make it better suited > for enterprise-level use. Well if I had my druthers (and fortunately I do, to some extent :) I'd like to have a set of external python scripts that handle kernel updates and kernel modules and all sorts of stuff like that - these scripts would come in the yum rpm by default but you could easily add more in a sane way. As it is - I want yum's default behavior to stay relatively the same. I like that it handles kernels correctly out of the box, I like that I don't have to tell people to specify some bizarre incantation to get kernels to install, let alone update grub.conf correctly. so make your list - and put them in some RFE's in bugzilla and I'll get through them as I can or as it makes sense. if someone wants to make patches against cvs for such things let me know - I'll be interested to see what can happen in the coming months to free up a lot of the older crufty code that eats up space in yum. -sv
