tech-pkg archive

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

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

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.


Home | Main Index | Thread Index | Old Index