Re: Silly Packaging Problem
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
Reply to: