tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg_install in base system again



On Tue, Nov 08, 2011 at 08:24:56AM -0500, matthew sporleder wrote:
 > On Tue, Nov 8, 2011 at 8:17 AM, David Holland
 > <dholland-pkgtech%netbsd.org@localhost> wrote:
 > > On Tue, Nov 08, 2011 at 01:09:14PM +0200, Aleksey Cheusov wrote:
 > > ?> > Or you could set $PATH correctly...
 > > ?>
 > > ?> If we have to explicitely skip outdated and buggy
 > > ?> pkg_* tools in base, what is the reason to have it in base then?
 > >
 > > So it works out of the box? To avoid having to bootstrap (an extra
 > > step that people won't necessarily understand)? To avoid having to
 > > bootstrap so that afterwards you have to remember that /usr/bin/make
 > > and /usr/pkg/bin/bmake are different and never accidentally mix them
 > > up?
 > >
 > > It's a serious usability issue.
 > 
 > Isn't the real problem here an inability to update this part of the
 > base system sanely?
 > 
 > Shouldn't pkg_install, at least, be able to upgrade itself?

It *does*.

   weatherwax% uname -r
   5.1_STABLE
   weatherwax% where pkg_add
   /usr/pkg/sbin/pkg_add
   /usr/sbin/pkg_add
   weatherwax% /usr/pkg/sbin/pkg_add -V
   20110805
   weatherwax% /usr/sbin/pkg_add -V
   20100204
   weatherwax% which pkg_add
   /usr/pkg/sbin/pkg_add
   weatherwax% 

I didn't have to do anything special to get that; it installed itself
at some point in the course of updating other packages, and then it
gets updated routinely like any other package.

The "problem" arises when people put /usr/sbin before /usr/pkg/sbin on
their path, thereby explicitly asking for the old version instead of
the autoupdated version. Then it naturally doesn't work.

The bug, if any, is that the system ships with a silly default $PATH.

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


Home | Main Index | Thread Index | Old Index