Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Sep 2011 17:10:51 +0200
From:      Polytropon <>
To:        Pierre-Luc Drouin <>
Subject:   Re: Best Server OS for Someone That Does not Want to Touch a Shell on a Regular Basis?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Mon, 05 Sep 2011 10:50:19 -0400, Pierre-Luc Drouin wrote:
> >> I noticed that in
> >> the past few years, updating softwares through ports has been requiring
> >> more user intervention, due to the way some dependencies are being
> >> updated from one version to the next. Would using binary packages allow
> >> to avoid more such user intervention?
> > Yes. All dependencies would be incorporated automatically.
> > Only ports without equivalent package that additionally have
> > OPTIONS to set would invoke a configuration screen, and this
> > screen would have to be dealt with only in the first run of
> > the updating process.
> >
> > There are also options for portmaster that can be used to
> > control program behaviour in case of problems (e. g. some
> > package not found, conflicting ports, versioning problem,
> > or port marked "broken").
> >
> So, what I was referring to in particulars was special updates like this:
> 20110517:
>    AFFECTS: users of lang/perl*
>    AUTHOR:
>    lang/perl5.14 is out. If you want to switch to it from, for example
>    lang/perl5.12, that is:
>    Portupgrade users:
>      0) Fix pkgdb.db (for safety):
>          pkgdb -Ff
>      1) Reinstall new version of Perl (5.14):
>          env DISABLE_CONFLICTS=1 portupgrade -o lang/perl5.14 -f 
> perl-5.12.\*
>      2) Reinstall everything that depends on Perl:
>          portupgrade -fr perl
> So you are saying that this type of special interventions is not 
> necessary when using only binary packages, right?

Erm... no, or basically yes. :-)

First of all, the example here refers to portupgrade, not
to portmaster.

The DISABLE_CONFLICTS variable is only required where
something is built from source. By using packages, you
can even _force_ installation of (maybe conflicting)
packages, implying of course that this may cause damage.

In _worst_ cases, there's the option to forcedly deinstall
packages and then re-install them (in a newer version),
this may be useful when the upgrade path is too much

Coming back to that example: If you order portmaster to
upgrade perl, you will traditionally also upgrade all
ports depending on it. And if this is possible via
packages (-P, -PP), it will "reconstruct" the dependencies
properly so all programs can use the new perl version.

However, as I've turned into a "compile guy" due to
sufficient hardware, I usually use source-based updates
when needed. I don't update my home system very often,
because I'd like to keep it in a functional state. :-)

So I've not come across that particular update yet, as
I still have perl-threaded-5.10.1_4 installed, and there's
nothing here that requires 5.12 or 5.14.

When you choose to use portupgrade instead of portmaster,
it's a good choice to always run "pkgdb -aF" before and
after anything you do (e. g. also "around" a pkg_add -r
command). I've been using portupgrade in the past, but
today I prefer "just ports" (home) and portmaster (work).

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

Want to link to this message? Use this URL: <>