Subject: update all, docs, binary pkgs, etc questions
To: None <tech-pkg@netbsd.org>
From: John Refling <johnr@imageworks.com>
List: tech-pkg
Date: 03/22/2000 12:04:08
1) Any way to set the destination of the "gzip'd tar ball"
for make package, ie, something with a dirname with the
machine architecture (sparc, i386) in it? Must be some
variable we can put in /etc/mk.conf. I greped thru all
pkgsrc/mk/* and didn't find the "gzip'd tar ball" string
anywhere, so am at a loss on this one.
2) Any way to make packages installed for a DESIRED package
be automatically uninstalled, once the DESIRED package is
built (assuming that the dependent package is not needed
at runtime of the DESIRED package, of coarse).
3) I agree with some other posters that the action of many
make targets is not what one would expect: the sequence
"make update; make package" will always fail since
"make update" does a "make clean" and there is nothing
to package up. [One can fix that by setting NOCLEAN=YES].
On the other hand the reverse sequence will always fail
if the package is already installed (presumably that's why
one would choose the update) because the "make package"
does a "make install" which fails if already installed.
So, one can find the "make package-noinstall" target.
Of coarse, if we want to build all kinds of hidden
functionality into each target, "make update" should
update the binary package automatically!
Is there any document describing all the targets of the
package make system (other than mk/bsd.pkg.mk)?
4) Regarding the Update All issue, it seems that there is
no Good Solution. I think the problem (as was pointed
out) is the difficulty of mapping the package name from
pkg_info (eg, tex-3.12321321) into its [future] build
directory, eg, print/tex. Chopping off the version
number and cd'ing to print/tex-* does work most of the
time, but not always. Clearly, there needs to be some
way to store the future upgrade process in the pkg db.
For my personal use, I have added a new target in my
mk/bsd.pkg.mk which after a REQUESTED build, constructs
and appends the [current] build subdirectory name to a
log file. So you end up with a list of directories
which you could automatically (cd $dir; make update) on
each one. Obviously this will ocassionally have problems
too, for example if I build in cdrecord and then later
cdrecord and cdrecord-alpha comes around, I won't get
the alpha version but only the [possibly] updated version
in cdrecord. Also note that I don't log the dependencies
this way at all.
the target is:
mypkglog:
echo ${PWD} | sed s,${PS},'$$PS', >> /var/mypkglog
where my global var $PS is set to my package src root dir.
5) Why is it that when I downloaded a current pkgsrc and I build
I need a more recent pkgtools? I expected that current pkgtools
would be integrated into the current pkgsrc, at least around the
time of a new release (1.4.2).