Subject: Re: make package
To: None <tech-pkg@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-pkg
Date: 06/27/2002 13:10:27
[ On Thursday, June 27, 2002 at 20:09:35 (+0700), Robert Elz wrote: ]
> Subject: Re: make package 
>
> Didn't the pkgsrc stuff get updated so it could detect when the work files
> were for an older version, and discard them all by itself?   This is such
> a common situation that I was pretty sure I had seen that someone had
> added that.

Well, partly.  The EXTRACT_COOKIE file is tested by the 'do-su-install'
target to be sure it contains the PKGNAME of the package about to be
installed, but although this is "just-in-time" for saftey's sake, it is
"too late" for solving all the other related issues.  Oddly this check
only triggers a warning message and then an extra "make clean && make
build", which may or may not be what the user expects....  :-)

I have a patch in use in my local pkgsrc which also triggers a warning
if "make extract" appears to have already been done in a dependent
package.  I don't think I've submitted a PR with it, but I may have
mentioned it on this list....

> Beyond that, whenever I see someone say that "you have to make clean ..."
> I wince.  Except perhaps in some extraordinary circumstances (like the
> clock being incorrect when a previous make was done, etc) no-one should ever
> be required to do "make clean" (or any equivalent).   That is, other than
> when they want to recover space of course.   Make (with the appropriate
> makefiles) is supposed to know when files are out of date, and recompile
> them, all by itself - whenever it doesn't, I regard that as a makefile bug.

Pkgsrc isn't really like any other place where 'make' might be used with
a 'clean' target.  Most of the time each individual 'make' invocation
expects the unpacked distribution tree to be present.

With my patch when a dependent package is being re-built and
re-installed there's an additional check for an existing EXTRACT_COOKIE
file.  Even then my existing patch only issues a warning since sometimes
I know ahead of time that I'll be upgrading a dependent package so I've
already done a "make build" in its module and so I don't want the parent
package to bail when it goes to install its dependencies.  I could make
it smarter I guess and compare its contents with PKGNAME and then make
it fatal, but with the do-su-install check and "fix" it's not really
necessary.

I.e. when you're about to build a package you're pretty much expected to
always start with "make clean" (if necessary).  If you know you've left
other junk around a "make clean-depends" is always a good idea too --
that way you don't have to do it later and restart your build!  ;-)

(if you can figure out a sure and "cheap" way to know when the extracted
WRKSRC directory is out-of-date then that would be a good thing -- I
thought of using the PKGNAME that's stored in the EXTRACT_COOKIE file
and then _always_ checking with every user-invoked target to ensure it
isn't out-of-date but that's a fair bit of overhead given the relative
benefit, and it's also dependent on PKGVERSION changing for _every_
reason that might require a rebuild)

>   | "make update" is a horrible hack, and should be purged from
>   | the tree, in my opinion.
> 
> That I agree with.

As do I! ;-)  I've never knowingly used "make update".  I'm afraid to
even try it!  ;-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>