portmaster deletes failed ports

Doug Barton dougb at FreeBSD.org
Wed Sep 6 20:51:44 UTC 2006

Bill Blue wrote:
> On Tue, 05 Sep 2006 10:09:58 -0700, Doug Barton <dougb at FreeBSD.org>
> wrote:

>> I'm extremely reluctant to start trying to think for the user. Down
>> that path lies madness.
> True enough.  But couldn't you anticipate the user a bit?

That's just saying the same thing using different words. :)  But, since at
the end of your post you mentioned that you're new to the FreeBSD ports,
I'll try to take your questions seriously.

> On Tue, 05 Sep 2006 14:47:03 -0700, Doug Barton <dougb at FreeBSD.org>
> wrote:
>>> The problem is that if unattended, you will not know if the port was 
>>> deleted especially if you have a lot of output.
>> I should have added in my previous reply that your statement above is
>> not accurate. If the install fails, that invocation of portmaster will
>> fail, which will cause all/any parent portmaster processes above it to
>> fail as well. Thus, in the event that a port fails to install, the user
>> will be notified of it immediately, and no further actions will be
>> taken.
> Also true, but under those circumstances what is the user to do?

That really depends on the user, the port, and whether they can live without
it or not. As I said in the post right before this one, I think that the
thing to do is to enable the backup feature by default, and then put
detailed instructions in the man page on how to recover from a failed install.

> If portmaster could detect ( as a result of errors that cause it to stop
> ) what the likely cause might be,

I think this is where you (and others) are going off the track. Portmaster
has no such divination ability. :) It can detect "failed" and "succeeded"
only, not "failed because ..."

> couldn't it advise the user what to try?
> I could be wrong, but it seems as though what is causing at least some of
> the deletions, is the /var/db/pkg database/fields not being accurate to
> the system,

This will not cause an install to fail, which is what we're talking about here.

> which can happen for a variety of reasons.  Should portmaster
> notice this type of discrepancy, couldn't it suggest to the user that
> running 'pkgdb -F' or equivalent would be a really good idea before
> continuing?

Portmaster checks the dependency tree for each port it installs "in line,"
which is to say if the install succeeds, any errors will be corrected, per
the user's instructions. I don't see any need to add a standalone
functionality for this, since portmaster never relies entirely on the
existing data to start with.

> Is the addition of a portmaster -resume option a possibility after
> whatever problem caused the stop had been fixed? 

I don't see any way to make that happen in a simple way, but if someone
wants to work up a patch, I'll consider it. My gut feeling is that there are
just too many variables here.

Your point about the config screens is well taken, however the real fix for
that is to fix the options framework in ways I described over the past week.

> Running from scratch
> each time, even in unattended mode, still means you have to wade through
> config screens over and over.
> It's not a big deal for the seasoned FreeBSD admin, but there's a lot of
> us that are relatively new to port and pkg management in general and may
> not yet understand the subtle differences between using portmaster vs
> three or four other methods of updating.

Fair enough. What would make this easier for you?

> Portmaster seems to be the most thorough, albeit somewhat mysterious from
> lack of feedback.

Have you tried running portmaster -v? I can always add more verbosity, but I
also don't want to annoy people who actually know what's going on well
enough not to need to be told. :)




    This .signature sanitized for your protection

More information about the freebsd-ports mailing list