Re: Feeping Creaturism vs. Disk Space
David H. Silber writes ("Feeping Creaturism vs. Disk Space"):
> Sounds contradictory, doesn't it? Actually, I have three Debian systems.
> One (firefly) has a gigabyte drive. One (aurora) has a 40 megabyte drive.
> What I would like to see in some future version of dpkg is the ability to
> block the installation of certain types of files on a per-system basis. For
> example, on aurora I could have a file /etc/dpkg/config, containing:
> prevent man
> prevent info
> prevent examples
If I implement this, it would probably be in the form of shell
globbing patterns to apply to unpacked filenames, so you could say
This is at once easier to do and more powerful and flexible.
I'm not sure how leaving out /usr/info/* would sit with install-info;
perhaps it could be encouraged to treat nonexistence quietly under
some circumstances. This would probably have to be non-default (I
think that having the default be to produce a zero exit status for a
nonexistent file is wrong).
> The reason I bring this up now is the discussion on keeping extra dpkg
> information. Some people are concerned about the amount of space that this
> information will occupy. I can see both sides of the issue. I really want
> the repair facility to be as feature-full as possible, because that might
> get me out of trouble some day. On the other hand, I can't afford the extra
> space on aurora. Perhaps my hypothetical aurora:/etc/dpkg/config would
> prevent status
I'm certainly planning to allow dpkg's many proliferating options (and
dselect's, when I get around to implementing them) to be specified in
a file in /etc. This is actually quite easy - I'll just arrange for
the file to be read as part of the ordinary option processing.
The real difficulty is how to fit them into dpkg's poor crowded
help screen :-).
I could do this feature - keeping permissions or checksums or
something - but I'm unsure as to whether it's worth it if the only
application is `repair'.