Fixed a few more minor nitpicks:

Fixed a few more minor nitpicks:

 - "apt-cache show" is more appropriate for us then
   "dpkg --print-avail"

 - the test that was supposed to find the correct name for
   the nspr and nss libraries didn't work correctly for
   distributions (e.g. natty) that for a transition period
   included both versions of the library. The new test has
   been verified to work with natty.

 - it is annoying that the "--clean" option sometimes fails
   with a hard-to-understand error message. We now always
   use "sudo" to avoid confusing users.

 - apart from dbus, some distributions apparently also keep
   rsyslogd running after installing the build dependencies.
   If this keeps popping up as a problem, we might have to
   eventually device a more generic solution.

 - when the user told us to remove an old install, try to
   remove all traces, instead of just the parts that cost
   a lot of disk space.

BUG=none
TEST=verify that we can install natty32bit (with debug symbols) and that afterwards Chrome can be built.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=128068

[Markus (顧孟勤), 2012-03-20 20:53:50]

The problem that Anton reported appears to have been a bug in
install-build-deps.sh that, as far as I can tell, would only show up when
installing natty in 32bit mode and with debug symbols.

This was the exact stage in the Ubuntu release cycle when the switch from
libnspr4-0d to libnspr4 happened -- and unfortunately, for the transition,
Ubuntu offered both packets; so, our auto-detect code made some unfortunate
choices.

I used the opportunity and fixed a few other minor nitpicks. Lemmy know, if you
need them broken out into a separate changelist.

[Michael Moss, 2012-03-21 00:36:49]

LGTM with minor nit.

https://chromiumcodereview.appspot.com/9764004/diff/1/build/install-build-dep...
File build/install-build-deps.sh (right):

https://chromiumcodereview.appspot.com/9764004/diff/1/build/install-build-dep...
build/install-build-deps.sh:99: if apt-cache show libnspr4-dbg >/dev/null 2>&1;
then
For consistency, and to avoid similar issues with other packages in the future,
should all instances of 'dpkg --print-avail' be changed?

[antonm, 2012-03-21 00:50:54]

Thanks a lot!

yours,
anton.

On Wed, Mar 21, 2012 at 12:36 AM,  <mmoss@chromium.org> wrote:
> LGTM with minor nit.
>
>
>
https://chromiumcodereview.appspot.com/9764004/diff/1/build/install-build-dep...
> File build/install-build-deps.sh (right):
>
>
https://chromiumcodereview.appspot.com/9764004/diff/1/build/install-build-dep...
> build/install-build-deps.sh:99: if apt-cache show libnspr4-dbg
>>
>> /dev/null 2>&1; then
>
> For consistency, and to avoid similar issues with other packages in the
> future, should all instances of 'dpkg --print-avail' be changed?
>
> https://chromiumcodereview.appspot.com/9764004/

[Markus (顧孟勤), 2012-03-21 06:21:31]

OK, I changed everything over to "apt-cache show" and tested with both lucid and
precise. It seems to be doing the right thing now.

I also noticed that we probably should try installing libjpeg-dev instead of
libjpeg62-dev, if available. On older distributions, this does actually install
libjpeg62-dev. But on newer distributions, we have the choice between
libjpeg62-dev and libjpeg8-dev. The latter is now the default and installing the
former ends up uninstalling a whole bunch of default libraries.

I hope, there isn't any strong compatibility reason why we should prefer
libjpeg62-dev over libjpeg8-dev, because that would make building on newer
distributions quite annoying.

[antonm, 2012-03-21 13:00:35]

Thanks a lot, Markus.  Doing another round of checks on my installation.

yours,
anton.

On Wed, Mar 21, 2012 at 6:21 AM,  <markus@chromium.org> wrote:
> OK, I changed everything over to "apt-cache show" and tested with both lucid
> and
> precise. It seems to be doing the right thing now.
>
> I also noticed that we probably should try installing libjpeg-dev instead of
> libjpeg62-dev, if available. On older distributions, this does actually
> install
> libjpeg62-dev. But on newer distributions, we have the choice between
> libjpeg62-dev and libjpeg8-dev. The latter is now the default and installing
> the
> former ends up uninstalling a whole bunch of default libraries.
>
> I hope, there isn't any strong compatibility reason why we should prefer
> libjpeg62-dev over libjpeg8-dev, because that would make building on newer
> distributions quite annoying.
>
> https://chromiumcodereview.appspot.com/9764004/