Re: suggestion: Host fly-off between pkgin and nih and subsequent official integration

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2013-04-16 at 13:28 BST, John Marino wrote:

> On 4/16/2013 13:47, Jonathan Perkin wrote:
>
> >Yes, this is somewhat apples vs oranges.  pkgin is a wrapper around
> >the pkg_* tools, and uses information in the pkg_summary file
> >generated by bulk builds to provide an interface for
> >installing/upgrading packages from an URL.
> 
> So if both pkgin and nim are only wrappers for the pkg_* tools, does
> that mean they suffer from the same integrity issues that I see with
> "make replace" and "pkg-rolling_replace"?

I've never used "nih", "make replace" or "pkg-rolling_replace", so
can't really comment on that.  However, in general, pkgin has no
issues upgrading packages other than the normal issues and
deficiencies inherent in pkgsrc (e.g. configuration management).

> Now I'm starting to wonder these package managers improve the
> situation for users that basically only build from source where the
> trunk branch is frequently pulled and the packages on the system are
> not guaranteed to be from the same set like you would see on a
> pkgsrc quarterly branch.

pkgin has no benefit to users who build from source, no.  It is for
users who wish to only use binary packages that they have built
themselves or are provided by a third party.

> My main motivation for this thread was to address this problem, but
> now it's not clear these new tools do that.

Again, I have no idea about "nih" so perhaps it is different, but
certainly it doesn't make sense with regards to pkgin, at least in its
current form.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com