tech-pkg archive

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

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



I've been wondering why the pkgsrc project hasn't held a "fly-off" between pkgin and nih in order to select an official package manager, and then integrate this directly into the mk/* framework such that the very first package built is this official package manager.

This is what the FreeBSD Ports Collection has done with pkgng and I think it was quite an improvement for ports. For pkgsrc, it seems like having an integrated binary package manager would "fix" the problems seen with the "experimental" "make replace" and untrustworthy pkg_rolling-replace. Now, not having used either pkgin or nim, I'm only assuming one or both of them are similar to pkgng where they have their own database and internally store package metadata which is why it needs to be built first. Hopefully my ignorance of these tools isn't invalidating my question.

So basically I'm wondering:
1) Would having an integrated binary package manager solve some of pkgsrc's warts and generally improve its usability?

2) If the answer is a resounding "yes", why hasn't the process to select and integrate one started?


I don't have an opinion which manager is better, and I don't know if there's a third candidate. I just think of the old American football axiom, "If you have two quarterbacks, you really have none." In the same vein, pkgsrc should evaluate these candidate binary package managers and integrate one of them rather than stick with "choice is good", especially when the default choice is "no manager.

What do others think?

John


Home | Main Index | Thread Index | Old Index