why update...

[b. f.]

>...if is doesn't work???
>
>It is not the first time and I think the last too but I have a question
>anywhere:
>
>The problem is jpeg 8.0 which need to update many ports. It is not a problem
>if works. But if doesn't which is my case that is a problem. As I sent a
>previous mails about problem to rebuilt qt33 and arts (not just me) and the
>problem became a BIG problem because many other applications don't work. Why
>all of this rush for update a port in this case jpeg which IMO is not so
>important (BTW Linux world use K3b for KDE 4 more than six months without
>problem, we don't) and update for QT33 doen't works??? Is it QT33 less
>important as jpeg 8.0. As a user of FreeBSD I expected that when update is in
>the port that is safe to use this port. But looks like that I am wrong.
>Thanks.


"Why update?" is a question that *you* should ask *before* you update
your ports tree, or rebuild your ports.  No one is forcing you to
track the latest ports tree, that is *your* choice.  Committers put in
a lot of work to try to ensure that large updates go as smoothly as
possible, but there are often some problems that go undetected during
test builds, and need to be fixed after the first commit.  If you
don't feel confident about resolving such problems yourself, then wait
for several days after a major commit for the dust to settle before
updating.  There are four major kinds of problems that often go
undetected by test builds:

1) problems that occur because of the presence of outdated or
conflicting ports (in the test builds, everything is built in a clean
sandbox, unlike on most actual systems, where the presence of ports
that haven't yet been updated or conflict but don't have the proper
CONFLICTS entries can break updates);

2) problems due to ports built with non-default build options (there
are just too many build options in ports to test every possible
combination of options, so most test builds just use the defaults;
users who use non-default options may have to work with committers to
fix any resulting problems);

3) problems that arise because portmaster, portupgrade, and other
build tools don't do what the test servers do (sometimes these
third-party tools are broken, or problems arise because the tools
leave outdated ports in place as they are rebuilding them, so that
users can continue to use the ports during the time that they are
rebuilt; this can lead to problems that can usually be circumvented,
but may break big batches of port builds);

and

4) run-time problems that occur after the updating of a port (there
are far too many ports, and too few of them have regression test
suites with complete coverage that are run before installation, to
test the entire functionality of every port as part of a pre-commit
test, so users can expect some problems to slip through).

You can cut down on the number of problems that you encounter from 1)
and 3) by removing all of the ports that you intend to update, and all
of the ports that depend upon them, before updating them.

There was no "rush", as you put it, involved with this update: the
committer announced his intention to do this on the mailing lists on
Jan. 24, then he worked with other committers to do a full test run,
before making any changes.  Again, you have the option of using a
previous version of the ports tree, or of using packages, or of
managing your updates more carefully, or of not using ports at all,
but some other packaging system.  You should expect problems from all
of these: nothing is perfect.