Fwd: nih questions and comments

[Aleksey Cheusov <cheusov%tut.by@localhost>]

sent from email which is not subscribed to tech-pkg@, sorry.

---------- Forwarded message ----------
From: Aleksey Cheusov <vle%gmx.net@localhost>
Date: Mon, Jan 5, 2015 at 4:12 PM
Subject: Re: nih questions and comments
To: Greg Troxel <gdt%ir.bbn.com@localhost>
Cc: Packages NetBSD Discussion Technical List <tech-pkg%netbsd.org@localhost>

Hello Greg.

On Sun, Jan 4, 2015 at 4:47 AM, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:

* commented-out repo path

The config files has a commented out repository line.   It seems that
this line is also built in and used when there is none configured.

The default repository is set in nih.default.conf which is loaded before user's config.

So, REPOSITORY should work out of the box without editing nih.conf.

You need no any modifications in config file for using binary repository.

Some other default values are also set in nih.default.conf and can be overriden

in nih.config.

* multiple repositories?

I'd like to be able to have a joint repo of packages I compile and the
standard builds.  I realize this puts me on thin ice consistency-wise.
The man page talks about repository in the singular.  It would be nice
to either explain that one can have more than one and how they are
searched, or explain that there is only one, and if this is a design
decision or what's-implemented-so-far.

Currently only two modes of work are supported:

- you use single binary repository from ftp/http/etc,

- you use your own FULL binary repository.

There is no way to combine them. I guess you want to always prefer

your own binaries over official ones. Right?

* nih verify defaults

It seems that (on a system which is in order) verify is mostly an
operation which should turn up no problems. So I would think the
default for verify would be to check everything that is reasonable to
check.

Maybe -dL is close to what average user wants to see as the default.

Option -m (checksums) is also helpful but takes much more time.

Additionally, for the "-s" option it would be nice to have a way
for example to suppress lines like:

  s: mismatch devel/distcc distcc-3.2 6.1

on a system with uname -r of "6.1_STABLE".  In that case, it isn't
really a mismatch.  But 5.x would be an issue. So I'd suggest two
flags, one for major version and one for any difference, and to make the
major version flag part of the default.

This option should have some knowledge about system it runs on.

On Linux it is probably useless. For now I implemented exact OS version match

just for simplicity and because I have no "good plan" yet.

* use of pkgsrc summary

The man page talks about building a summary from pkgsrc.  But it's not
clear how that's used, in terms of update operations.  Does nih include
the ability to do what pkg_rr does?  Or is this just for status?

More intelligent pkg_rr analog (handling package union and split, for example)
has not been implemented yet. So, yes, currently pkg_src_summary may be used for status

(installed packages vs. pkgsrc, and this operation works very fast) and package
search (nih search -p, nih refresh -p efficiently/incrementally builds pkg_src_summary
for pkgsrc).

Can one use the pkgsrc summary info and also a remote repo?  What if they
don't match?

Upgrade is possible only with a help of binary repo. Search is possible in pkgsrc too.

See nih {search,meta,info} -p and "nih refresh -p".

* installed by user vs automatic

There are flags -u and -a.  Obviously (with a grain of salt), this
refers to the absence and presence of automatic=YES, and there's really
only one setting.  If so, it's confusing to have two words and two sets
of flags.  If there are two flags, that's confusing too.

Internally there is only one flag automatic=YES.

So, -u and -a are antonyms.

* keep flag

This seems sensible.  It would be nice to document the variable that is
used, and for someone(tm) to add this same variable to pkg_rr.

pkg_admin set keep=YES

I have to document it just like it did for try-out flag. Thanks for the note.
 

It's hard to tell from the man page what happens when one combines keep
and updates.  Without a consistent build, some things are bound not to
work, and it would be nice to have the rules documented.

If a package is marked with "keep" flag it is not updated. This flag was stolen
from Debian's dpkg.

* v4/v6 defaults

I can see the point of having flags to be IPv4 only, but it seems
strange to make v4-only the default.

I made this the default for myself. Nearby I have no any ISP who provides IPv6.

I'll remove this default in the next release.