In article <41BB3098.70805@tworoads.net>,
	srp@tworoads.net (Scott Presnell) writes:
> Hi Folks,
> 	I'm in the midst of upgrading my i386 system
> from NetBSD 1.5 to 2.0.  At the system level things
> seem to be going well.
> 
> WRT packages, I had been hacking buildlink files to
> keep packages from being "needlessly" updated.
> 
> Now I'm trying to make a fresh start. I have some questions:
> 
> 1) native pthread:  should I take this opportunity to remove
> any pthread packages and rebuild packages with the system/native
> /usr/lib/libpthread?  Or is there still a role for the package
> based pthread?

I think you're better off blowing GNU pth away. GNU pth is quite
stable, but it confuses pkgsrc, at times, to have two different
libraries of the same name in the path. NetBSD pkgsrc is supposed
to prefer the native versions when they exist, anway.  Native
pthreads in NetBSD 2.0 work just about as well as GNU pth. The
only problem I encounter is that "mozilla-gtk2-1.7.3" freezes from
time to time, but I seem to remember it doing that with pth as well.
(Next rebuild, I'm going with Firefox.)

> 2) how do /usr/lib/libintl and the gettext-lib package work
> together?  Often I get link results such as:
> 
> /usr/bin/ld: warning: libz.so.0, needed by /usr/pkg/lib/libgnomeui.so, 
> may conflict with libz.so.1
> /usr/bin/ld: warning: libintl.so.0, needed by 
> /usr/pkg/lib/libgnomeui.so, may conflict with libintl.so.2
> 
> (same question for zlib I guess)

Same answer. I believe all packages are able to use native pthreads
and native zlib. The situation with "libintl" is worse, because a
few packages actually require GNU libintl. My solution is to remove
the "/usr/pkg/lib/libintl.so" symlink after the subject package is
built. (Keep the ".../libintl.so.N" symlink to run against. This is
a groovy ELF feature.)

> 3) I'm trying to use /usr/pkgsrc "-current" I guess, rather than
> one of the quarterly freezes.  Is there a branch of the package
> system I should try to use in outfitting a newly updated 2.0 system?

The current HEAD is a good choice. It's currently in a "freeze" leading
up to a new branch, so it should be quite usable, and any build bugs
you report should be fixed right away.  You could start on the HEAD,
and then track the upcoming branch, to avoid those gratuituious updates.


Frederick