portmaster deletes failed ports

[Craig Boston]

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