tech-pkg archive

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

nih questions and comments



For a long time, I've built packages that I used from source, and only
recently explored binary package managers (pkg_chk -a doesn't really
count!).  For no good reason, I ran pkgin first, and now I'm trying out
nih.  I have a lot of questions/comments, and ideally they'd be answered
in the docs :-)

First, thanks to Aleksey for writing this.

* more defaults

Overall, my reaction is that it requires a bit too much thinking to use,
and it would be nice for the defaults to be closer to what a normal user
should do, even if they don't understand.  Specifics below - I know such
a broad comment is not that useful.

* 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.
While I usually like programs to work with empty config files, I think
the remote repo should be manifest in the file.  So I'd be in favor of
the default config file actually having the path, and no repo being used
if there is no (uncommented) line.

* 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.

* 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.  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.

* 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?  Can
one use the pkgsrc summary info and also a remote repo?  What if they
don't match?

* 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.

* 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.

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.
 
* 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.

Attachment: pgplPGX0_3k0g.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index