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

Re: policy suggestion (seeking discussion)



On Sun, Apr 26, 1998 at 01:23:06PM -0400, Carl Mummert wrote:

[added Cc: to debian-policy]

> Question:   when does dpkg write the /var/lib/dpkg/info/*.list ???

When installing, when removing, and when purging, by the looks of things.

ie, currently whenever dpkg adds or removes a file belonging to a package,
it notes it down it its info/package.list file.

> Situation:  Package X has something in the post-inst script which
>             the developer knows will create file F, which dpkg will
>             not know about (known problem).

The current suggestion on how to deal with this is by using an
"extrafiles" dpkg control file that the package includes which lists
the files it could end up creating, either in the maintainer scripts,
or in general operation. Example contents of extrafiles are the files
in /usr/lib/cruft/filters/*, btw.

The text of the proposal itself is at http://va.debian.org/~ajt/, the
rationale &c. are best found by looking through the -policy archives
under the Subject: PROPOSAL: Extrafiles (was...).
 
> Suggestion: Package X could, if the files already exist at this point,
>             include 'cat "F" >> /var/lib/dpkg/info/X.list ' in the
>             post-inst list.  This would associate the newly-created file
>             with the newly-installed package, and would prevent the
>             buildup of cruft which otherwise would develop when package
>             X is removed.
> 
>             The postinst script is the perfect time to do this, because
>             this script knows with 100% certainty which files it creates.

A quick comparison of the two approaches:

With the extrafiles approach, you don't know if the extrafile was just
lying about before hand, and just *seems* to have been made by the package,
or if it really was.

Also, extrafiles doesn't provide any mechanism for dpkg to automatically
remove extrafiles. (This is seen by some to be a Good Thing(tm), though)

With the above approach, odd things might happen if two packages want
to share a file (/usr/bin/vi, for example is shared between the various
vi clones by using the alternatives interface)

Also, the above doesn't provide any convenient way to specify groups of
files, for example /var/spool/news/comp/os/linux/announce/2600 would be
difficult to associate with inn.

I've probably missed some points in the above.

> I have tried this by adding (by hand) a new package to (...)/status and
> a corresponding lists file to the info dir.  When I ran dpkg --remove
> on the package, the files listed went away.

Not a particular problem with your proposal, but please note that Klee
and/or Ian apparently plan on changing those data structures significantly
in the future. Apparently they'll still be text though. (yay! :)
 
Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

      ``It's not a vision, or a fear. It's just a thought.''

Attachment: pgpoDPOK6Vh_l.pgp
Description: PGP signature


Reply to: