Re: Is there a tool which keeps track of space on filesystems during install?
>>>>> "Itai" == Itai Zukerman <zukerman@math-hat.com> writes:
Itai> I think this functionality belongs more properly to dpkg.
Itai> You want to stop dpkg from unpacking a .deb that it
Itai> *suspects* won't fit in the space left. It *suspects* that
Itai> it won't fit if after unpacking the .deb files there won't
Itai> be any space left. That can be tested without unpacking the
Itai> .deb.
dpkg should just abort with an error if it can't unpack the package,
and apt-get should not try to unpack any more packages, if such an
error occurs.
Itai> The pre/post-inst/rm scripts complicate things slightly.
Itai> Preinst might free up some space, for example. Still, I
Itai> think a warning (or controlled error) might be better than
Itai> outright failure and potential database corruption. What
Itai> happens when /var fills up?
IMHO, this is a more important issue. Especially when postinst scripts:
a) generate files that use more disk space (eg. any package with
(x)emacs LISP files).
b) not all postinst scripts are designed to abort when an error
occurs, so dpkg might consider the package fully configured, when in
actual fact it is seriously broken.
Sure, this is a bug in the package, but I am not going to be the one
to test XXX,XXX packages and file bug reports against all that fail...
So I don't know off hand any packages which do have this problem, but
I would be extremely (but pleasantly) surprised if no packages were
buggy.
For instance, previously I installed a LISP package (sorry, can't
remember what package; the error has since been fixed), and not known
the installation failed until I try and use that particular feature.
After hours of hair pulling, I find that the log files shows that the
build for a certain file failed, but the installation never considered
it important to tell me.
However, I would really like to know how much disk space is required
before I even down-load the packages...
(might be tricky for postinst scripts, but lets ignore that for now;
at least that would be a good start)
--
Brian May <bam@debian.org>
Reply to: