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>