Re: Building and running new package versions not yet in pkgsrc?

["Thomas Mueller" <mueller6724%bellsouth.net@localhost>]

> > What do I do if I want to build and run a package where pkgsrc version is
> > not up-to-date, and I want to build and run the current release version of
> > that package, like Abiword 2.8.6 for instance, when pkgsrc version is far
> > behind?  Or maybe I want to try a new alpha or beta development release of a
> > package like Firefox or Seamonkey, but don't want to burn my bridges on
> > the already installed and running version.

> Well, maybe you can help to improve pkgsrc by adding a newer/develop- package 
> to the "wip" section of pkgsrc. "wip" means "work in process" and you are 
> able to make and upload packages. If you are working on those packages it 
> would make sense to make your work available to others... And your work is 
> done in a coherent environment.

> To take your example "abiword"... You can take a copy of that package and do 
> some modification to it Makefile etc.)... If the package builds and runs 
> stable it can be used to update abiword in pkgsrc.

> > Can I create a testing install base such as /extra or /usr/extra, and set
> > something like
> > PATH=/usr/extra/bin:$PATH
> > and perhaps modify some other environment variables, and then be able to
> > return to the regular environment?  I would only want to change a few things
> > temporarily and would not want to create an entire chroot system.   

> I think maybe "DESTDIR"- support is what you are looking for... You should be 
> able to find it in pkgsrc- Guide.

> Best regards,
> Helge

I think the "wip" section of pkgsrc is at http://pkgsrc-wip.sourceforge.net/ ?

Anyway, it would be good to be part of the community, gaining insight from 
others' efforts and others gaining if I successfully build a new package. 

I notice many packages offer a configurable DESTDIR environment.  Then such a 
build can be conveniently be packaged into a .tgz, .tbz or .txz without having 
to find the bits and pieces in many places.  

The idea of putting an extra path such as /extra or /usr/extra optionally in 
front of the regular path is to be able to run such a package without 
destroying the older, established version.  I need to experiment and make an 
appropriate shell script.  I remember doing something like that with OS/2.

Tom