Re: pkgin 0.5.1 now available in pkgsrc

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

>       Nobody runs 5.1 official bulk builds AFAIK due to lack of
>       hardware.  This is why we still have binaries for Q1.

> ... and John Klos followed up on November 10:

>       I'll have them up and running tonight.
Yes. I'm well aware of his bulk build.
5.1 still points to Q1. Maybe upload is in progress.
I think you can ask him personally.

> Am I to understand that the latest stable pkgsrc version (2011Q3)
> on the latest stable NetBSD (5.1) on the likely most widely used
> architecture out there (i386) doesn't have binaries fully available?
Yes, the sad fact :-( This is exactly why John Klos started to run
the bulk build. Right?

> That being admitted, administering my one tiny home desktop is
> getting to be very frustrating, and a time expenditure that's hard
> to justify.  :-(
Actually, with minimal problems you can use 5.0 binaries on 5.1.
I do so sitting on current.

1) output of "pkg_lint_summary -L pkg_summary-50.txt" on NetBSD-5.1

  L: not_found /usr/X11R7/lib/libXfont.so.1 fonts/bdftopcf bdftopcf-1.0.2
  L: not_found /usr/X11R7/lib/libpixman-1.so.0 devel/pango pango-1.28.4nb1

This means that bdftopcf and pango packages requires libXfont.so.1 and
libpixman-1.so.0 libraries respectively that are absent on 5.1.
These library exist on 5.1 but with bumped shared lib major number.
So, the are incompatible.

  Solution: rebuild bdftopcf and pango packages from sources.

2) osabi-5.0 vs. osabi-5.1. osabi package sticks to a particular version
   of NetBSD.

  Solution: rebuild osabi package and its direct dependent packages
  (STk, p5-perl-headers, pftop and x11-links) if you use them.

3) "nih mark -k p5-perl-headers pftop x11-links pango bdftopcf"
   for marking them non-upgradable from binaries.

4) continue to use nih.

 >> You can try pkgtools/nih :-)

> Having just spent a few hours trying to learn to use one tool, I'm
> not eager to repeat the experience immediately with another one,
> especially in view of the fact that your best claim for nih over
> pkgin (in nih/README) is the choice of language and database package
> used to implement pkgin!  Not very persuasive IMHO.
I'm a software developer. This was *my* motivation. Using "C" for this
kind of things is just waste of time. This is my point. As a user you
can compare functionality, usability and stability.

> And I actually *like* that pkgin is just a layer on top of the
> built-in pkg_* tools,
The same is true for nih. It works on top of pkg_*. Everything else is
supporting utilites making it so powerful and flexible ;-)

> and seems to cooperate with them fairly well so
> I can use a bit of this and a bit of that without problem.

> I'm sorry to seem so grumpy, but at this point I *am* pretty grumpy.
> My SO dreads whenever it's time for me to upgrade my software;
> apparently I turn into an ogre for the week-end.  So far he has
> not persuaded me to switch to his beloved Slackware, but something
> is going to have to give.  My desktop requirements are simple.
0 ~>pkg_info -a | wc -l
    1035
0 0 ~>

Everything is managed by NIH.

> Spending this much time in system administration in what is supposed
> to be my time off has to stop.

> If I come up with a constructive suggestion, I'll let you all know. :-/

> In the meantime, I started "pkg_chk -u -f -k",
I used pkg_chk for several year before writing nih.

> intending to just fetch the material so I could replace the packages
> at my convenience, but I misunderstood the manpage, and over 400
> packages have been deleted.
nih asks stupid questions before doing destructive actions ;-)

BTW, "nih history" says what packages were
installed/upgraded/downgraded/removed/remarked. So, you are able to
restore them at any point in the future.

> The program is now fetching them back, and I suppose will reinstall
> them over the course of the next few days, if nothing goes wrong.
nih stores downloaded binaries in cache directory. So, you need not
redownload them again and again.

> Argh.  I'm now remembering why I switched to pkg_rolling-replace at
> some point, only to decide that it was too slow and redundant.  My
> last software upgrade was done by deleting everything and installing
> it again manually.  Double Argh.  There has to be a rational way to do
> this.
Forget about nih/README. Try it.

-- 
Best regards, Aleksey Cheusov.