On Wed, Feb 15, 2012 at 12:12:39AM +0100, Marc Espie wrote: > > (Unless you're a *developer*, or you want to *downgrade* ports, > you should never ever have to run make clean=plist > that's stupid. register-plist catches *bugs*.) > > Nope, won't work. You haven't de-installed the troublesome package, so a > new build will still break. (e.g., it doesn't have > make clean=install). > > > That's the crux of the matter. > > Eventually, we'll solve most of these. Not all of them, not ever. Because > the number of combinations old package installed/new package build is very > very large, so the best we can hope is to fix the most common ones > (having our own libtool for most of the tree does help a great deal). > > There are so many things to do... this is not a huge priority. We don't > fix the ports tree, we fix binary packages. Once they're all perfect > (ah ! :) ) we'll fix every little remaining bug in ports. > > Promise ! :) > > (I'm not promising anything, actually, since there's always always more > polishing to do for binary packages proper). >
I do see how complicated things are. My attempts to upgrade a perl port with other ports depending on it has been very helpful in seeing how tough it can be to upgrade something since it fans out into a bunch of other stuff. I have not been able to make out how to deal with existing ports depending on my upgrade that fail many regress test, both before and after my updates. If a new port I am trying to build does the same, seems difficult to decide what to make of the failures (unless its something obvious such as requiring a newer perl than is in base). CPAN shows many modules with multiple failures in testing. My attempts to bring in some new perl ports also shows a long chain of dependencies, which when someone else updates them, might break my work. And I find a lot of regress depends that are not in ports at all. I am not even sure whether I should then add those also, which adds up to a lot of new ports just to regress one new port. Studying existing perl ports shows some requiring regress stuff such as p5-Pod-Coverage, while others do not, even though that shows up as test dependencies in the build directories. I am also frequently finding that perl modules require other modules that are NOT listed in Makefile.PL or Pod manuals. I have been grepping use and require in the build directories to search for dependencies. Is there a less eye straining command sequence to use? Thanks, Chris Bennett
