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