[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
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.
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
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.
Main Index |
Thread Index |