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

[John Marino <netbsd%marino.st@localhost>]

On 4/16/2013 15:52, Aleksey Cheusov wrote:
> To be honest. I think this is absolutely useless. First, it just doesn't
> improve usability.

I am very aware you're an interested party and I'm being very careful to 
avoid offensive statements and I also don't want to fall into "well, if 
you like $SOMETHING so much, just use that instead" situation.

That said, pkgng absolutely improved usability over previous functionality.

> Second, this may lead to circles in package dependencies.

It doesn't.

> Finally, have a look at Linux systems.
> Debian and some of its derivatives, for example, have two package
> managers: apt and aptitude. I think this is a right way. Personally, I
> don't  like what FreeBSD devs did.

I can't ascertain any significantly differences between apt and pkg, and 
pkg-devel is still adding features.  In some areas, pkg is clearly 
superior to apt.  In general they should be considered comparable.  I'm 
also comparing pkg to what was available on DragonFly before (not Linux) 
and it's representing well.


> FreeBSD devs decided to bury pkg_* because their pkg_* was, sorry, just
> a crap.
> If you compare man pages of pkgsrc's and FreeBSD pkg_add, for example,
> you'll see the difference. They didn't have even pkg_add -u! The same
> for -U, -A, pkg_admin etc. etc. etc.
> This is why their higher level tools worked directly with pkgdb.
> So, situation with pkgsrc is completely different. Both pkgin (AFAIK)
> and nih work on top of pkg_* and this is good. We don't need pkg(1).

I've personally found pkg_add to be extremely flakey to the point I 
didn't bother with prebuilt binaries anymore.  But since that was a 
while ago and since I probably can't replicate it repeatably, let's 
assume that's not valid anymore.

I can say pkg is extremely fast and self-contained.  I don't know what 
database pkgdb is based on, but it's doubtful that it can outperform 
from a speed perspective pkg's sqlite-based db.

> What we currently lack is ability to [re]build packages and then install
> them using _single_ tool. I plan to implement this in nih.

This is an honest criticism that others share with me:  Pkgsrc does very 
poorly in the scenario of frequently pulling the trunk branch and 
building a package.  First, due to revbumps, it's continuously trying to 
rebuild dependencies that FRANKLY don't need rebuilding.  And then it 
fails because the package is already installed.  And then you have to 
one-by-one use "bmake replace" (you have to want until each one 
inevitably fails) because you FRANKLY don't trust rolling-replace.  So 
you are stuck at the console for the better part of an hour babysitting 
a process that should be able to run on it's own.  And you started by 
only wanting one new package.  The criticism comes in that pkgsrc 
project doesn't recognize this as a problem, that somehow the user is 
misusing it.  I personally think this is a significant problem that 
greatly reduces the usability of pkgsrc.  At the very least, it 
encourages prebuilding a subset of packages in a chroot in order to use 
something like pkgin/nih to handle updates more smoothly.  I'm just not 
seeing the same type of issue on ports.

John