Odin just told us rpmdrake would not be complete for 8.0. That's not kewl, but I guess we'll have to live with that :) Since we are speaking of rpmdrake, I have more suggestions/complains : - rpmdrake should not fail because of one little conflict in a package. Example : I wanted to install all emacs and xemacs packages. I should have remembered that xemacs-extra should not be installed in parallel with emacs, but it is friday evening you know... Anyway, rpmdrake took some time downloading all the packages, and after that stopped the install because of the conflicting xemacs-extra. First, it would be great if the conflict was detected *before* the actual downloading. And even if not, why not install as much packages as possible (for exemple all emacs packages), leaving only the conflicting ones and dependancies to reinstall ? Another example : if I try to upgrade my uptodate Mdk 7.2 to the unsupported rpms, i have a list of more than many dozen packages to download. I know (I tried it but don't remember the details) that at least one conflict occur and breack the whole installation after all the packages are downloaded. I don't want to start the upgrade again because ed-XXX.rpm is in conflict with blinking-ls-XX.rpm. Summary : it would be great to have a more fine grained conflict handler in rpmdrake. - after an update in cooker rpmdrake (most recent version), the selected (and then installed) packages list is not refreshed. Remark that with an usual install (not upgrade) all seems to work well. - filling the trees in rpmdrake (the little progress bar in the bottom of the window) is very slow. I don't know if it would be possible to made it quicker, but it would be very cool. In general, media handling give an impression of slowness on Mdk. For example, debian apt is much more quick (at least on my machine). I know that debian apt does not store individual files (as urpmi does) in their index files, but in order to give a good feeling the whole process should be more responsive. Maybe by doing some kind of "factorization" in a DB backend? Another example : after having installed some packages, the whole trees are reconstructed. A more incremental approach would be better. After all, deleting one or some nodes in a tree should be quasi-immediate. That's all I have in mind for now. I hope some of those ideas (and others) could be incorporated before Mdk 8.1, so that rpmdrake will be *the* package tool :) Pascal
