On Thu, Dec 26, 2013 at 12:56 AM, Doug Barton <do...@dougbarton.us> wrote:
> On 12/26/2013 12:41 AM, Matthias Andree wrote: > >> I disagree on the assessments of efforts here. I checked the docs, >> and the actual .db files are supposed to be compatible, >> > > Sure, they are, to some extent, SUPPOSED to be compatible. Experience > tells us that is not the case. > > > excepting the >> corner cases mentioned in the wiki. The manual effort only exists for >> ports using BDB in transactional mode, while most ports just use it >> as a key-value data vault. >> > > So you're volunteering to walk every user whose stuff gets broken through > the repair? > > > Ttbomk, deprecated does not cause build failures, and even if so, >> WITH_BDB_VER=5 would fix that. >> > > portmaster treats DEPRECATED as a fatal error. I did neglect to point that > out in my previous post however. > > Finally, I would like to see technical or other_compelling_ reasons >> >> why we would need 48 in the tree in the future. >> > > Well shouldn't that argument go the other way around? Shouldn't the people > proposing the purge be the ones to provide _compelling_ reasons to do the > purge? > > > Doug > I updated from 9-Stable to 10.0-RC3 dy before yesterday. I had one odd error during the upgrade, but managed to complete the upgrade. Then I re-built all ports. I had a few issues, all resolved except one that i have opened a PR for, but I did have a very annoying time with Berkeley DB. I had deleted all ports, so I assumed that port requiring Berkeley DB would use db5 or db6. But, as Doug noted, no such luck. As Doug pointed out, this is because some ports require db4x. Specifically, databases/evolution-data-server required db41. No option for any newer version. apr1 required db42+, but that just pulls in db4* forts, so no db5 gets installed, even though the port clearly stats that it works with 5. So 4.2+ really means any db4. version. There is no reason that ports using "USE_BDB=4.\+ could not have been found (by a simple grep) and been "fixed" to use db5 (assuming that they really do work with db5), but they were not. Or the Mk files could have caused the cases where db4.\+ were called for that this could not have installed db5 or even db6 rather than insist on db4. (And, quite oddly, the LOWEST db4 version that allowed was the one installed when no matching db was installed. Rather than mess around with fixing multiple Makefiles while my system was unable to do much of anything, I just removed the DEPRECATED lines form db41, db42, and db43. I'll need to go clean them all up, now. And some don't even make it clear that they will run with db5. And I still have seen no reason that the db4 ports really needed removal. They still work fine and are widely used. Deprecation was just asking for trouble. (Don't forget that a "DEPRECATED" statement in a port Makefile is fatal.) I will also mention that the man page for portmaster REALLY needs to be updated for pkgng. This wasted just a bit more of my time. Due to the iconv move to base, the "quick and dirty" rebuild option of "portmaster -aD" fails miserably. I suspect portupgrade would have a similar problem, but I have not used it in a couple of years, so I can't be sure. On the whole, I have to call this one a really botched change that should be rolled back until it can be implemented to work properly, at least for a clean install of all ports. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
