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

On Thu, Feb 10, 2005 at 07:49:36AM +0000, Alistair Crooks wrote:

> > cc directed to tech-pkg, to which the question probably should have=20
> > been posted
>=20
> You mean something like this:
>=20
> ----------------------------
> revision 1.42
> date: 2004/08/13 13:34:42;  author: agc;  state: Exp;  lines: +9 -4
> Modify pkg_info so that it will only print information on uninstalled
> binary packages in the current working directory if -. is given on the
> command line. If no -. is given, pkg_info will look for its information
> in the ${PKG_DBDIR}.
>=20
> This addresses a long-held gripe on the part of a number of people,
> including myself, which completely violated the POLS.
>=20
> Bump version for this and previous pkg_admin modification.
> ----------------------------

while I agree with the intent of the change, the implementation still
has some problems:

% pkg_info ./mutt-1.4.1nb3.tbz
pkg_info: can't find package `./mutt-1.4.1nb3.tbz' installed!

quite obviously, I have deliberately asked for pkg_info on a filename
in the cwd. I have explicitly specified a filename on the command
line. the problem this was attempting to fix stems from this particular
bit of code in lib/path.c:path_create()

        if (path =3D=3D NULL) {
                path =3D "."; /* XXX */
        }

I presume it was written this way because the TAILQ stuff is unhappy
with an empty array. the XXX to me indicates that this is a
hack/workaround and should be fixed.. the comment at the top of the
function says:

 * =3D> if NULL is passed, use "." instead. XXX

personally, I fixed this problem in my own tree by substituting the
"." with "/tmp/nonexistent" - perhaps not an elegant fix, but the
behaviour is more consistent and obvious (if a path to a binary pkg
file was given, use it. otherwise, look for an installed pkg -- without
the behaviour - and need for an arbitrary flag - which violates the POLS).

it would seem the real fix here is to sanitise the use of the TAILQ
stuff so that this problem simply goes away.

grant.


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

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

iD8DBQFCCxyvluYOb9yiFXoRAvFHAKCRads5++hM6e2JYoJ6eEoqX4kJUACgpwjF
xwfyjl4ce58tNoeac/rEcH8=
=R7g/
-----END PGP SIGNATURE-----

--k4f25fnPtRuIRUb3--