Re: Deleting uncompressed Info/Doc files at upgrades
>>>>> On Thu, 22 Oct 1998 14:27:04 -0700, Chris Waters <xtifr@dsp.net> said:
Chris> Manoj Srivastava wrote:
>> Heh. Seems that dealing with each of the 21 ``logical groups''
>> shall pretty much need a general solution.
Chris> Hmm, I strongly agree with you up to and including the quote
Chris> above.
>> Modifying dpkg to deal with these logical groups is a astoundingly
>> bad idea.
Chris> Here, I might disagree. I agree that it would be a bad idea
Chris> to modify dpkg to deal with each of these individually.
Chris> However, a general-purpose metadata solution, which should
Chris> merely require a hook into dpkg, might well be a useful
Chris> solution.
Hmm. I the simplest change to dpkg involves two parts:
1) Another file that dpkg knows about that it will use to classify
files by type (it doesn't need to know about the types) so that
when it creates it's /var/lib/dpkg/info/*.list file it has '<file
name> <file type>' on each line rather than just '<file name>'.
This could be a rather large change so maybe instead a new
file *.filetypes could be used instead.
2) It would have to call a 'fix-filetypes' script at the end of each
install/setup/whatever. I'm not sure the correct place. In this
call it would pass all the file names of packages that had just
been installed. It would then be the responsibility of the
fix-filetypes script to parse the file and do the appropriate
things.
We'd need a new package 'dpkg-filetypes' or something. This would
contain the 'fix-filetypes' script, and the config files describing
what to do with each filetype (/etc/dpkg-filetypes/*) and the scripts
that actually do the work (/usr/lib/dpkg-filetypes/*). The config
files setup how the sysadmin wants things handled (delete docs,
compress them whatever).That way all the logic is in a filetype
specific area. Also we could add filetypes by just installing a file
in /etc/dpkg-filetypes and /usr/lib/dpkg-filetypes (so that the
emacsen-common could install those two files, and instead of calling
things in the postinst scripts emacsen-common would work automagically
just by labeling the file types).
I've just thought of another three things to make it
easier^H^H^H^H^H^H more complicated, but I will quit now.
Chris> Before we do any such thing, though, I'd recommend that we
Chris> investigate the current status of the Gnome project's metadata
Chris> plans. *IF* (and this is a big if) we can find a metadata
Chris> solution that is simple and elegant, solves our issues with
Chris> documentation *and* the 21++ other "logical groups", and is
Chris> compatible with Gnome, I think we'd have something to be
Chris> downright proud of.
Hmm. the above could be started and moved into a metadata format by
allowing multiple 'filetypes' where each setup file got it's crack at
the file based on the meta data and dpkg wouldn't have to know
anything except to setup the extra file with filename -> data mappings
(which would just mean copying a file like postinst to the correct
place).
The big problem I see with the above would be speed. But I can also
see a couple of ways around that.
Another problem is that it might be nice to never allow docs on a box
if the sysadmin has decided that they dont want them. The above
doesn't handle that. Maybe a set of hooks in the dpkg binary would be
better. At certain times in the installation process it would go out
and look if there is a hook to be called for this filetype and do
appropriate things based on return call. Obviously this gets A LOT
uglier. :)
Just random musings,
Dres
--
@James LewisMoss <dres@ioa.com> | Blessed Be!
@ http://www.ioa.com/~dres | Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach
Reply to: