Summary and response: On Wed, 4 Jun 2003, Robert G. Brown wrote: > Dearest yumsters, RGB: !! I hear great things about you and time and space. > I've been trying to shoehorn openoffice onto my laptop, which is > remarkably low on / diskspace, " One may never be too wealthy, too healthy, nor have too much (processor speed|ram|harddrive) -- me " > a) If yum fails the check for disk space, it should immediately check > to see if space can be recovered by cleaning the package caches (of all > packages that are NOT on the current install list) and offer to do so. A) Why not run add this, cronned as a 'clean' phase process to so this anyway in the existing cron process ile? An RFE will be so proposed by me in the Bugzilla if it seems a good idea at the end of this discussion. I think Seth is busy shacking on another project for a few days. > b) If yum STILL fails the check for disk space, and has several <snip - partial splits> > approaches, each embodying a certain degree of AI and arcanity, suggest > themselves: B) I have written shell code which first tries 'piece-wise' alphabetically (How's that for AI?) presently downloaded single packages, and if it succeeds in installing them, rm's them one off. It then tests for and if present tries 'package' and 'package-devel' pairs ... same outcome on success I have a few 'tuples' for samba, and so forth as well. (Of course, this simply replies on RPM itself to confirm that the unitary, pair, or tuple dependency is properly addressed.) It turns out that after a week or two, space frees up and (hopefully, usually) all that are left are the complex ones and enough newly found space, to effect a yum mediated resolution. Much safer. But probably outside of the scope of yum proper. I tried a rejected RFE like this in the Bugzilla, and discussed it with Seth in IRC, and can abide the result. > i) looking on other root-writeable partitions for sufficient free > space to hold the rpm's themselves, and if it is found prompting the > user for permission to create a temporary toplevel ./yum/package cache > for the duration of the install. B2) ouch -- I think of yum in update mode, as like RPM -- not calling for user intervention within its scope. The confirmation prompt can of course be over-ridden with the '-y' option for those who would routinely grant 'yum' permissions. Leaving transient download caches seems vulnerable to simply causing hard to diagnose DoS on filesystem problems. As a defensive admin, I'm against it, as it would really make matters harder to track down when they get 'horked'. And absent an 'atomic' transaction, which yum cannot do, it will happen. Also, thinking about AI, there are no natural limits on how creative yum should be -- why should not yum then use a clever AI routine, and look for open non-root writable NFS shares, and chroot into that user id to find space. And contrary wise, if the root-writable space is a 'sticky' directory (chmod 1777), yum has to then look for, detect, and respond to race attacks from malevolent users. Or it may fill a /var/log/ type partition and inadvertently kill a daemon needing the space. Too scary. > ii) Trying to do an "in place" install where it installs package A, > removes rpm A (freeing the space for) package B (installed then rpm > removed) and package C (installed then rpm removed) etc. This could > theoretically "work" but is of course both less robust and may not be C) see "A" above -- no theory -- it works using the existing cached file locale. It would work in local directories, but for the "B2" reasons, I would not so expand yum. -- Russ Herrold
