[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/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
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
Forget about nih/README. Try it.
Best regards, Aleksey Cheusov.
Main Index |
Thread Index |