Re: fixing bugs in packages

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Fri, May 11, 2012 at 10:19 AM, Martin Husemann 
<martin%duskware.de@localhost> wrote:
> On Fri, May 11, 2012 at 09:59:56AM -0400, Julio Merino wrote:
>> I has always worked for me, and for many others.  What are the
>> problems you are seeing?
>
> Various - I guess you would blame all on inconsistent/partial updates
> of pkgsrc and say "this mode is not supported".
>
> During long lasting work on changes, I often have to update the pkgsrc tree,
> for various reasons. And as soon as one of the (already installed)
> dependencies of the pkg I am working on get their pkg revision bumped, the
> next "make replace" will fail. And to rebuild that "changed" dependency, I
> have to kill my pkgobj directory - which is a no-go with unfinished
> changes in that directory.
>
> So, overall I have never seen "make replace" work for me when a simple
> "pkg_delete -r" followed by a pkg_add of the binary pkgs available wouldn't
> have worked.

Has this happened recently?  Because what "make replace" does today is
"make package" followed by a pkg_add -u of the package... which
basically amounts to your idea of "pkg_delete + pkg_add" of a binary
package.

I don't remember seeing the kind of problems you mention, and I've
been using make replace a *lot* over the years.

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

That's true, but in these cases even the "make install" will take a
long time as well.

> Why should I need to jump through this hoops, just to run some test code?

What are the alternatives to the current approach?  This surely can be
improved, but there need to be concrete ideas first.

-- 
Julio Merino / @jmmv