Precedence for shadowing a monolithic Fedora package?

[Michael Schwendt]

On Sun, 23 Aug 2009 13:22:10 -0400, Michel wrote:

> On Sun, 2009-08-23 at 18:53 +0200, Michael Schwendt wrote:
> > On Sun, 23 Aug 2009 12:35:46 +0200, Nicolas wrote:
> > 
> > > Using alternatives seems appropriate, but you can also rename the
> > > binary and the .desktop file so you can have a completely parallele
> > > installable version.
> > > 
> > > Conflicting and Obsoleting fedora maintained packages have be avoided.
> > 
> > Nah, explicit Conflicts are fine in that case.
> > audacity vs. audacity-freeworld is one example.
> > Users need to choose between either one.
> > 
> > Relocating an application and all its files it may read/write just
> > to make it parallel-installable with another build of the same/older/newer
> > application is just not worth the extra effort. And if you don't relocate
> > or rename config/run-time files, there's the risk that this causes
> > side-effects since one app is built with more features than the other
> > one or is a different version even.
> 
> In this case, not *too* much of an effort:
> 
> $ rpm -ql sonic-visualiser
> /usr/bin/sonic-visualiser
> /usr/share/applications/fedora-sonic-visualiser.desktop
> /usr/share/doc/sonic-visualiser-1.6
> /usr/share/doc/sonic-visualiser-1.6/COPYING
> /usr/share/doc/sonic-visualiser-1.6/README
> /usr/share/doc/sonic-visualiser-1.6/README.OSC
> /usr/share/icons/hicolor/48x48/apps/sonic-visualiser.png

Does it maintain config files?
 
> but yes, having a Conflicts: should be good enough. In this case, I
> should not be using Obsoletes: and Provides:, right? Unless there are
> other packages that depend on sonic-visualiser being installed, that
> could make do with sonic-visualiser-freeworld.

Well, it could depend on /usr/bin/sonic-visualizer instead, which
is not expensive (*bin* is covered by the primary metadata) and would
be more accurate anyway. Alternatively, provide a capability and make
dependencies require that one.