[Pkg-chromium-maint] Bug#746034: chromium depends on non-existent (in testing) libudev0

[Edward Welbourne]

Source: chromium
Version: 34.0.1847.137-1~deb7u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm on testing.  <quote src="cat /etc/apt/sources.list.d/*">

# Norwegian national repository:
deb ftp://ftp.no.debian.org/debian/ testing main non-free contrib
deb-src ftp://ftp.no.debian.org/debian/ testing main non-free contrib

deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib

</quote>

In aptitude, when I select chromium, it's an instant conflict due to its
dependency on libudev0 >= 146, which is not available.  I am
consequently unable to install chromium in testing.

This is particularly irksome due to the reason I uninstalled it to begin
with: I had, some months ago, experienced persistent conflicts between
chromium-browser and chromium-inspector; nothing I tried would resolve
this, for several weeks; eventually, I'd tried uninstalling both and
reinstalling the browser, which worked (and pulled in the inspector,
without any apparent problem).  I got similar conflicts this morning so
did the same, only to find I got this different conflict instead on
reinstall.  At the time, a version of libudev0 was in fact listed, as
deleted but with some config files remaining; it had been deleted when I
uninstalled chromium, which was the only package depending on it.
Unfortunately, trying to select it for installation was ignored by the
aptitude UI.  Once I'd purged it (to clear the config files) it was no
longer listed; it's apparently not present in testing.  So, if I hadn't
uninstalled chromium, I'd have had a perfectly good libudev0 lying
around that I could have continued using.  Unfortunately, chromium's
internal conflicts had left me little option but to uninstall it.

Fortunately, stable still has a libudev0 with a high enough version, so
manually downloading and dpkg -i-ing that works round the problem,
enabling me once more to install chromium-browser (and get the whole
pile of other chromium stuff I don't want chucked in with it).  ... hmm
... and, on doing that, I see apt-listbugs reports exactly this problem,
so why didn't reportbug tell me about it ?  Possibly something to do
with the fact that the package isn't installed ... so I'll post as a
follow-up instead of adding another duplicate.

Somewhere at the bottom of all of this is a basic error in dependencies
among the chromium family of packages: I only actually want the
chromium-browser package, but it depends on chromium, which depends on
chromium-inspector, which I don't want or need.  But for that, I'd not
have hit the conflict that forced me to uninstall and left me in a
broken state.

As long as the chromium package is going to depend on
chromium-inspector, i.e. be a "top-level" package to pull in the whole
chromium suite, it should surely also depend on chromium-browser, not
the other way around.  If there are common packages that the diverse
chromium-* programs all depend on, e.g. libudev, then there should be a
chromium-common package on which they all depend, with chromium
depending on the high-level packages, not depending on the low-level
things they need so that chromium-browser has to depend on that in order
to get everything and the kitchen sink along with the libraries it
needs.  I should be able to install the browser without the ancillary
tools that aren't actually needed in order to run the browser.  Sure,
it's good to encourage web designers to actually check what they
produce, but that's no reason to burden the browser with an extraneous
Depends - it should at most be a Recommends.

Until this is fixed (given that there's a FTBFS problem on 32-bit
delaying that), how about persuading the libudev maintainers to restore
libudev0 in testing ?

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash