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

[John Marino <netbsd%marino.st@localhost>]

On 4/16/2013 13:02, Aleksey Cheusov wrote:
> On Tue, Apr 16, 2013 at 1:12 PM, John Marino <netbsd%marino.st@localhost
> <mailto:netbsd%marino.st@localhost>> 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
>     replace"
>
>
> 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).

John