[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#540939: upgrade has broken several packages: gcj-4.4-jre-headless cannot be configured



On Fri, 11 Sep 2009, Matthias Klose wrote:
> >Setting up gcj-4.4-jre-headless (4.4.1-1) ...
> >update-alternatives: error: alternative rmiregistry can't be master: it is a slave of java
> >dpkg: error processing gcj-4.4-jre-headless (--configure):
> >  subprocess installed post-installation script returned error exit status 2
> >
> >This problem then causes several other packages to not be configurable
> >because they have dependency on gcj-4.4-jre-headless.
> >
> >These broken packages are causing other problems and I cannot remove them
> >without uninstalling important packages like openoffice.
> 
> the recent dpkg doesn't allow mixed master/slave alternatives
> anymore. Not sure how dpkg deals with this when a user has such
> packages installed, and then upgrades to the new dpkg.

On upgrade, dpkg will remove the master alternative "rmiregistry" if it's
also slave of another alternative.

You should thus ensure that all packages agree on what's slave and what's
master.

> the only "fix" I can think of would be adding conflicts to every
> package listing rmiregistry et al as a slave alternative. But I
> don't know these packages, so it's likely that we close this report
> as a won't fix.

You can ask the bug submitter at the very least to find out.

You should certainly add conflicts or breaks to known packages
shipping the bad alternative. You can also clone the bug report
and reassign it to the package shipping the bad alternative.

Why shouldn't rmiregistry be a slave of java? If it's only because it's
shipped in another package, it might not be a big deal.
update-alternatives will happily accept missing slaves and the same
--install call duplicated in another package will add the slave symlink
when the slave has appeared.

Cheers,
-- 
Raphaël Hertzog


Reply to: