[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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,
@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: