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

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 

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: