On Fri August 11 2006 04:51, Ian Jackson wrote: > Bruce Sass writes ("Re: Silly Packaging Problem"): > > "files" and "size" accommodate the desire to include generated or > > packageless files and their size (if knowable) in the dpkg DB. > > This is a bad idea. dpkg maintains these lists of files not > primarily for the purpose of dpkg -S, but rather for making the > package management operations (install, upgrade, remove, etc.) work > properly. > > If you start editing these files (even with the relevant lock held > and with regard to the package status), dpkg will behave differently > afterwards: it will think the file in question was shipped in the > currently installed package's .deb.
iow Hacking the DB may work while the system is static but not in the middle of (say) installing 2+ pkgs. > This is almost certainly not what you want. A good general principle > is to practice ownership: dpkg should remove and update things it has > installed; maintainer scripts and other programs should remove and > update things they created. It looks to be what is wanted, eventually anyways. Queueing the update-package commands and processing them after dpkg finishes could work? I agree with that general principle, in this case dpkg already owns the data (list of files in the package and Installed-Size). ;-) [insert "dpkg DB->.deb" vs. "dpkg DB->system" argument] [insert ".deb->created files" vs. ".deb + created" argument] > If the objective is to make dpkg -S more useful (a worthy goal) then > you need a separate list for each package, of files which should be > reported in -S but which dpkg should otherwise ignore. It looks like ensure_packagefiles_available() in filesdb.c would be the place to do this (essentially duplicating most of the action in lines 115-172 with a different filelistfile, maybe only if doing -L or -S?), afaict, but my C's pretty old and rusty. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]