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

On Tue, Apr 16, 2013 at 5:28 PM, John Marino <netbsd%marino.st@localhost> wrote:

On 4/16/2013 15:52, Aleksey Cheusov wrote:

That said, pkgng absolutely improved usability over previous functionality.

Previuos functionality provided by FreeBSD ports? ;-) Definitely!

I participated KievBSD in 2011 where I presented my nih and

had a lot of talks with FreeBSD users and developers. But I think in pkgsrc

the situation is completely different. pkgsrc's pkg_install works just fine

in comparison to FreeBSD's pkg_*.

Second, this may lead to circles in package dependencies.

It doesn't.

In case pkgsrc/nih you'll introduce circles because it has dependencies.

pkgin is selfcontained.

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.

The same for pkgin and nih. I'm very well aware of apt functionality.

I cannot say too much about pkgin, but nih provides some functionality

absent in apt/yum/zypper/pkg/pkgin.

I'm also comparing pkg to what was available on DragonFly before (not Linux) and it's representing well.

Is it time to try out pkgin or nih? ;-)

pkgin works (builds update plan) much faster but spends time

for creating a database. nih provides more cool features. This is a dilemma.

Several years ago pkgin crashed for me on Linux and handled "automatic"

flag incorrectly but I don't know is this still a problem or not.

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.

More important than existing bugs (yes, there are some bugs in pkg_install)

is that pkg_install provides "API" which is good enough for building normal

package manager on top of it. pkg_install also provides flexible pkgdb

(no idea how fast it is in comparison to sqlite or latest bdb).

I use some of its features in nih. I also think that pkg_install is better

than Linux's rpm and dpkg for a number of reasons.

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.

revdumps is completely different problem.

And then it fails because the package is already installed.

I'm not sure I understand you here. pkg_add -U?

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.

Package building should be done only in chroots or VMs if we have root priviledges.

FreeBSD oldtimers may disagree with me.

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.

This is not a problem of pkgsrc. This is a problem of those who use wrong tools for package building ;-)

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.

I planed to combine nih and distbb to solve this problem a couple of years ago.

Unfortunately I could not find enough time for this. But this task is feasible.