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 13:02, Aleksey Cheusov wrote:
On Tue, Apr 16, 2013 at 1:12 PM, John Marino <
<>> wrote:

    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.

I think I understand why people may want to see "official package manager"
but it's not clear for me what is the purpose of "integration",
especially if you say
about mk/*. Can you explain?

Sure. In ports, the mk. has been modified such that pkg (the "official" binary package manager) is automatically included as a dependency for every single port. Rather, this will be the case for FreeBSD release 8.4 and 10. For earlier releases this is not the default behavior, but it can be switched on.

The reason is that pkg has its own database which is not compatible with the pkg_* tools databases. You have to use one or the other. FreeBSD has a way of converting from the "old" database to the pkg one, but it's probably easier just to rebuild everything from scratch.

In this case, it makes sense to have the package manager always installed first to build out this db, and that's handled in Mk/*

    For pkgsrc, it seems like having an integrated binary package
    manager would "fix" the problems seen with the "experimental" "make

It's well known that "make replace" is only for pkgsrc developers :-)

I don't know of any other way to do it other than rolling replace though. It seems like it is for anyone that tries to build from source rather than prebuild binaries.

    and untrustworthy pkg_rolling-replace.

pkg_rolling-replace cannot be replaced when you have no root access
(shell servers)
or have several pkgsrc instances in the system. So, it is definitely
useful tool.

What it purports to do is useful, but the few times I've tried using it, it failed (IIRC some packages were removed from repository and RR just choked on those that were installed but not in pkgsrc). Based on what I saw, it's not production quality.

      Now, not having used either pkgin or nih, 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.

JGYI. nih doesn't use any db for metadata. It uses pkgdb and is based
solely on pkg_install.

Alright. Part of pkg's benefits and speed gains come from the use of sqlite and its built-in commands replace basically all the slower pkg_* tools. If both pkgin and nim use the same database as pkg_install then the benefit of integration is much less as you can just install it anytime for the same effect (I guess).


Home | Main Index | Thread Index | Old Index