pkgsrc-Users archive

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

Re: pkgin 0.5.1 now available in pkgsrc

>       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/ fonts/bdftopcf bdftopcf-1.0.2
  L: not_found /usr/X11R7/lib/ devel/pango pango-1.28.4nb1

This means that bdftopcf and pango packages requires and 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
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.

Home | Main Index | Thread Index | Old Index