Re: New APT version
On Thu, May 21, 1998 at 10:29:12AM -0600, Marcelo E. Magallon wrote:
> On Thu, May 21, 1998 at 12:20:51AM -0500, Manoj Srivastava wrote:
> > Well, I think that putting the information into the Packages
> > file is a bad idea -- especially for large packages. We need a line
> > per directory and there is no reason to inflate the packages files
> > for packages we ain't even updating.
> I agree with you here, but I must point out that this information is most
> useful is it's available before downloading the actual .deb files. If the
> information is located in the Packages file, GUI apt could display partition
> usage information while selecting pacakges. If the information is available
> after downloading the deb, the only thing command line apt can do is issue a
> warning telling the user that the files won't fit, but the file is already
> downloaded (BIG problem for Emacs, IRAF, tetex, kernel-sources)...
Perhaps we are overkilling the problem?
The problem we're trying to avoid is partial-installation of packages (or
even starting the download) without having enough space to install them. A
set of heuristics would be sufficient to stop all the nasty cases, with just
a small probability that we would disallow a download that might fit after
- most (?) users have only one Linux partition anyway.
- for those with multiple partitions, /usr, /var, /usr/local, /home, /tmp
are the most likely directories to be split off of root.
- Debian packages don't contain anything from /usr/local, /home, or /tmp.
- Almost all (95%) of contained data is in /usr somewhere.
So why do so much extra work? Simply check that /usr has at least as much
free space as the uncompressed size of all packages, that /etc and /var have
some small percentage of that, and that /var has enough space to hold the
compressed packages as they are downloaded.
That should deal with almost all situations. If we want, we can then catch
obscure cases after downloading but before installing, by using Manoj's
'du' file included in the DEBIAN directory of each package.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org