Checking /usr/local/ before upgrading

[Fergal Daly]

On 30/10/2007, Christofer C. Bell <christofer.c.bell at gmail.com> wrote:
> On 10/29/07, Pär Andersson <paran at lysator.liu.se> wrote:
> >
> > That is really wrong, placing something stupid under for
> > example /usr/local/bin should really not break upgrades or any other system
> > software. Please read chapter "9.1.2 Site-specific programs" of the Debian
> > Policy Manual, Fergal provided a link and a quote of the most relevant part
> > in his e-mail.
>
> There's nothing wrong going on here.  This was a simple case of user
> error.  The user installed software (albeit under a different release)
> that was not compatible with the current release.  The system was
> configured to use software installed in /usr/local prior to being
> upgraded, and continued to do so after being upgraded.  That this
> software was incompatible with the newly installed operating system is
> not the fault of the operating system.

Vincenzo said most of what  I was going to say.

There are 3 choices for policy. Ubuntu can:

1completely ignore /usr/local for all system operations
2.1 allow /usr/local in PATHs etc in system scripts but search it last
2.2 allow /usr/local in PATHs etc in system scripts and search it first

Some consequences:

1 your system will never break because of /usr/local
2.1 probably nothing will fail because of /usr/local and the user can
choose to influence the version of tools/libs used by the system
scripts by removing .deb packages and populating /usr/local
2.2 things can easily fail due to the contents of /usr/local, the only
way to find out whether an operation will fail is to attempt that
operation and observe the result, even an expert user can do no better
than that.

Also for 2.2, all troubleshoooting docs should start with "please sudo
mv /usr/local/ usr/local.bak and see if the problem is reproducable"
(of course it's not as simple as that if /usr/local is a mount point).

You are advocating 2.2. The only advantage I can think of is that you
can easily override the system versions of libs and tools but it seems
that if you really know enough about the system to do that safely, you
would be able to produce a custom .deb file and instal that.

Could you explain what advantages you see from 2.2 vs 1?

F

> ie; There is nothing to be learned by over analyzing this issue other
> than a valuable life lesson on the part of the system administrator.
>
> --
> Chris
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>