Re: Precedence for shadowing a monolithic Fedora package?

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

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.