Bob Bernstein <poobah%ruptured-duck.com@localhost> writes: > On Mon, 17 Mar 2014, Greg Troxel wrote: > >> But I stand by my comment that basically updating everything is good >> practice, and avoids lots of trouble. > > Without meaning any impertinence, please allow me to respond. I would > never gainsay your comment above, especially with its caveat > "basically." I seem always to encounter trouble when I stray from my > "basic" practice of working with *relatively* frequent "cvs up's" of > the pkgsrc tree. Sure - this is certainly a useful discussion. > My impression has been that one of the virtues of the pkgsrc system is > that one need not keep all packages up to date. In the bad old days of > small drives and slow processors this was a decided plus. Right now > lintpkgsrc shows I have approximately 120 packages out of date with > the CVS tree. This makes sense (to me) since this > currently-under-discussion install of NetBSD was first populated with > userland packages from the collection 'pkgsrc-2013Q4'. A terminology nit: "userland" in BSD refers to user-space components of the base system, separate from packages. It's true that pkgsrc in theory will let you update things randomly. But what I was trying to say is that updating everything bottom-up is safer. I didn't explain that the reason is that most people who work on pkgsrc keep things up to date, and the various combinations of old things are not well tested - even if it we'd agree it's a bug when something fails. > I have never understood these quarterly package releases, and never > have been able to stay with one until the next appears. I always seem > to need/want something that is in CVS but not elsewhere, and so > eventually do a (eek!) 'rm -rf *' in /usr/pkgsrc and then a cvs > co. This time around I once again returned to one of these releases > hoping to have a different experience, but alas it was not to be. You should not need to rm -rf and checkout fresh; cvs update should work fine (and does for me). The point of quarterly branches is to provide a relatively stable set of packages, with only security fixes and other fixes of similar severity. And, it's a starting point for bulk builds of binary packges, which can be installed by people without building things. What I do on a number of machines is to keep my pkgsrc tree at the most recent quarterly release. Then, as the freeze approaches, I start rebuilding everything (via pkg_rolling-replace), and keep doing that, because really my main point is to help make the quarterly branch as high-quality as possible. Then, during the quarter, if I want something newer than what's in the stable branch, I'll update just that package to head via cvs up -A. Or, I do this and update the package. This is technically on thin ice, but usually it's ok. Also, I use ccache, which greatly eases rebuilding. > Right now I don't think I am suffering all that much as a result of > those 120 out-of-date packages residing on my Unix machine, which I > hasten to add is a Micron full tower dual PPro-180mhz 256Mbyte ram > sporting twin 9 gig SCSI hard drives. How long to update those 120 > packages? I'd rather not think about it! But somehow I think the > funders of pkgsrc wanted to take that burden from my > shoulders. Perhaps, Dr. Troxel, you are one of them! I am too new to be a founder :-) So given that your machine is old (but I'm sympathetic to using old machines), you might want to investigate using nih or pkgin and binary packages to update each quarter, and then being judicious about building things that you can't wait for the next quarter to upgrade. I don't really see any options other than patience or expending CPU time.
Attachment:
pgpYBpy6IwjYg.pgp
Description: PGP signature