Subject: Re: More Update All
To: None <>
From: Alistair G. Crooks <>
List: tech-pkg
Date: 03/27/2000 01:02:22
> Why can't a few new targets be added to mk.bsd.pkg called
> something like "make tag_for_update" which will simply
> store the current package's directory (eg, print/tex) into
> a data base.  You would run this from any package which you
> want updated in the future.  You wouldn't want this flag
> recursively carried into the build of dependent packages,
> since dependancies for a package may change in the future.
> Then, when you download a new pkgsrc.tar.gz from current,
> you would go to its root dir, and type
> "make update_all_tagged_for_update" which would simply enter
> each directory stored in the data base made above, and do a
> "make update" or whatever is appropriate.
> The approach of storing the package's directory is version
> independent in most cases, as far as I can tell.

If you look at the output from pkg_info -b, you can see the
binary package's path relative to the pkgsrc root:

% pkg_info -b kdeutils
Information for kdeutils-1.1.2:

Build version:
misc/kdeutils/Makefile:# $NetBSD: Makefile,v 1.34 1999/12/06 21:00:12 bouyer Exp $
misc/kdeutils/files/md5:$NetBSD: md5,v 1.8 1999/09/15 18:26:03 tron Exp $
misc/kdeutils/files/patch-sum:$NetBSD: patch-sum,v 1.3 2000/02/29 19:43:57 jlam Exp $
misc/kdeutils/pkg/PLIST:@comment $NetBSD: PLIST,v 1.11 1999/09/15 18:26:03 tron Exp $
misc/kdeutils/pkg/PLIST.SunOS:@comment $NetBSD: PLIST,v 1.11 1999/09/15 18:26:03 tron Exp $


As you note, packages do change their location over time, so anything
that is added would have to take care of failure modes very well.
Indeed, we are long overdue a cleanup of the structure of pkgsrc
categories.  Maybe after 1.5...