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).