On Wed, Sep 06, 2006 at 08:17:29PM -0700, Freddie Cash wrote: > This is why blindly running -a is not recommended. A good habit to > get into is to develop an upgrade procedure that does not include -a.
-a isn't so bad when combined with -i so it prompts you about each port. Of course that's not very automated, but recent versions of portmaster seem to cache the yes/no responses from the config stage now and batch all the actual builds together, which is very nice. I'm in the habit of always using -i anyway, since portmaster has an unforuntate habit of trying to install ports that it thinks are dependencies but in reality aren't required (bison 1.x comes to mind, I also recall having trouble with it trying to install win32-codecs when it was already present). In the past I've commented out this "feature" and just relied upon the port itself to install whatever deps it may need, but haven't done that since verion 1.6 or so when -i stopped prompting me multiple times. > Just because a port update is available is not a good reason to > blindly upgrade every single installed port. Especially if it has KDE or OpenOffice in the name ;) > pkgdb -F will not help portmaster in any way shape or form. pkgdb is > a portupgrade tool that reads the files under /var/db/pkg and creates > the /var/db/pkg/pkgdb.db file. Only the portupgrade tools use that > files. Actually pkgdb -F can help clean up incorrect / inconsistent dependency information in the /var/db/pkg/*/+REQUIRED_BY and +CONTENTS files, not just portupgrade's internal database. That and pkg_cutleaves was the only reason I kept ruby installed for so long, but portmaster -l is good enough to not bother installing it on new boxes. Though I still think "leaf ports" and "root ports" should be listed together. Slight tangent: the ports tree unfortunately still records wrong dependencies sometimes when there's more than one port that can satisfy it. MIT Kerberos vs. Heimdal used to be the classic example. Now I run into it with slave ports such as subversion (compiled with WITH_PERL and WITH_PYTHON) vs. the subversion-perl slave port, which svk wants. We really need a good solution to fix this across the board (adding more bsd.*.mk files is NOT a good solution), but I can't think of anything workable that doesn't involve massive changes to the way dependencies are recorded for packages. > > Is the addition of a portmaster -resume option a possibility after > > whatever problem caused the stop had been fixed? Running from > > scratch each time, even in unattended mode, still means you have to > > wade through config screens over and over. > > I thought portmaster used config-recursive starting with 1.6 or > thereabouts, so you only go through the config screens once at the > start of the run. Yes, but if a build fails you still have to go through them again for any ports that weren't upgraded yet (when you restart it after fixing the problem). I'm pretty sure the -G option was added specifically to address this case. As long as you haven't run cvsup / portsnap, you can be sure that all the options are already set the way you want them. PS, in case I haven't said it before, many thanks to Doug for writing portmaster! Between it and the integration of csup into the base, it should now be much quicker to get from initial install to compiling (freshly updated) ports. Craig _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
