Subject: Re: Finding non-pkgsrc files with pkg_admin
To: Hubert Feyrer <hubert@feyrer.de>
From: Peter Bex <Peter.Bex@student.kun.nl>
List: tech-pkg
Date: 04/18/2005 11:53:09
--AXxEqdD4tcVTjWte
Content-Type: multipart/mixed; boundary="mhOzvPhkurUs4vA9"
Content-Disposition: inline


--mhOzvPhkurUs4vA9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 18, 2005 at 11:03:21AM +0200, Hubert Feyrer wrote:
> > I understand.  I don't see why @exec files have to be `manually' remove=
d by
> > @unexec though.  They have to be created dynamically, but they don't ha=
ve
> > to be `deleted dynamically', do they?  In the end it's just an RM state=
ment
> > on a file that was put in place by the pkg system.
>=20
> The list of files is also used to create binary pkgs, and if it was=20
> included, it would not only be deleted, but also included into binary=20
> pkgs, which is not wanted.

That's unfortunate :(

> > Wouldn't it be better to let these @exec statements also generate an en=
try
> > in the database and let the removal of the files created by the @exec
> > statements be handled by the usual deletion system?
>=20
> I think that's more complex than needed, as you'd have to note what files=
=20
> the @exec calls create. You can just @unexec the necessary actions to=20
> remove them.

You don't have to note that automatically, you could just let the pkg
creator deal with this and add relevant entries in PLIST.  (something
like a @dynamic statement in the PLIST, for example)  Of course, an
automated aid to do this (a la `make print-PLIST') can be constructed if
necessary.

If necessary, the pkgdb.byfile.db database could be extended to include
a field that records the type of file (dynamic/static, and perhaps even
@dirrm directories).  It would be nice if the database really did
replicate ALL file-related information in the +CONTENTS of pkgs.

> > That way, pkg_info -L is correct, too.  At least, the manpage for pkg_i=
nfo
> > doesn't mention the dynamically generated files at all.  ATM it creates
> > the impression that it should list all files, which it doesn't exactly.
>=20
> Feel free to send me a patch for pkg_info.1 that tells that files created=
=20
> by @exec are not included. :)

How about the attached patch?  It's rather hard to put into words what
this means exactly without assuming the reader knows about the
technicalities of the pkg system.  But it should (IMHO) at least hint
at the fact there may be files that are not listed but still part of
the package.

Thank you for all the insightful information.

Regards,
Peter
--=20
http://www.student.kun.nl/peter.bex
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
							-- Donald Knuth

--mhOzvPhkurUs4vA9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="pkg_info.1.diff"

Index: pkg_info.1
===================================================================
RCS file: /cvsroot/src/usr.sbin/pkg_install/info/pkg_info.1,v
retrieving revision 1.47
diff -r1.47 pkg_info.1
129c129,130
< for everything are generated.
---
> for everything are generated.  This does not list files which were created
> dynamically during the process of adding the package.

--mhOzvPhkurUs4vA9--

--AXxEqdD4tcVTjWte
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iD8DBQFCY4OELg33BXzVMqsRAmgKAJ9f/akuY9dWZr3YdLEXzG5jcSoyKQCgjD9/
S+8uqOlDmgmFB4hfVq5/q70=
=EHqL
-----END PGP SIGNATURE-----

--AXxEqdD4tcVTjWte--