Re: fixing bugs in packages

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Fri, May 11, 2012 at 04:19:19PM +0200, Martin Husemann wrote:
 > This is all unneeded pain when all I want is run a few changed .so files
 > in gdb. It probably doesn't matter for simple pkgs, but I am talking about
 > things like:
 > 
 > -rw-r--r--  1 martin  users   34M Mar 14 22:45 ocaml-3.12.1.tgz
 > -rw-r--r--  1 martin  users   34M Mar  5 11:15 ocaml-3.12.0nb5.tgz
 > -rw-r--r--  1 martin  users   25M Feb 10 17:49 xulrunner192-1.9.2.24nb3.tgz
 > -rw-r--r--  1 martin  users   25M Jan 17 15:19 xulrunner192-1.9.2.24nb1.tgz
 > -rw-r--r--  1 martin  users   25M Jan  5 10:22 xulrunner192-1.9.2.24.tgz
 > 
 > where even creating and compressing the tar takes noticable time.

There are two different problems here:

(1) having to make clean and build from scratch after changing
something;

(2) going through a full stage-install and binary package hoo-ha just
to update a few files after inserting debug printfs or the like.

Both of them are significant costs. For large packages starting over
from scratch can take a couple hours, which is a waste of computer
power and of developer attention. The full install and package dance
is not *that* expensive even for very large packages, but it gets
annoying if you end up doing it very often.

However, there are different levels of "changing something". Editing a
file is one thing; all you have to do is remove .build_done and
friends. This is easily done by hand, although a rebuild target (and
maybe also re-configure, etc.) would be convenient.

Trying to adjust an existing work directory after updating parts of
pkgsrc that it depends on, however, is probably a lost cause, and I
don't really think it's worth chasing after. Although I wonder if

   mv work/ocaml-3.12.1 save/
   make clean
   make patch
   rm -r work/ocaml-3.12.1
   mv save/ocaml-3.12.1 work/

wouldn't do the trick in most cases. At least if the updates didn't
change configure results and so on. If they did, you're pretty much
out of luck.

As for doing partial installs direct to /usr/pkg... that seems
problematic. If it works at all to do "make build-env" and then "cd
subdir; make DESTDIR= install", which it might or might not depending
on the package, that's probably the best you're going to get. There
are enough packages that wire in DESTDIR at configure time that trying
to switch it around on a per-install-run basis isn't going to work in
general.

-- 
David A. Holland
dholland%netbsd.org@localhost