That ole Livna Problem/That ole VLC Problem

Axel Thimm Axel.Thimm at ATrpms.net
Sun Jan 20 06:49:51 UTC 2008


On Sat, Jan 19, 2008 at 10:40:36PM -0500, Lamar Owen wrote:
> On Thursday 17 January 2008, Chris Jones wrote:
> > Lamar Owen wrote:
> > > They initially set up livna to watch DVD's.  Then they get a nice
> > > ivtv-based MPEG enocder card, and decide to set up MythTV.  ATrpms is
> > > 'THE' place to get MythTV for Fedora.  So they set up ATrpms.
> 
> > > Now they install vlc.
> 
> > In which case they should look into yum priorities. The following page
> > is for Centos, but explains the principle.
> 
> I'm using priorities myself, on my OpenNMS/nagios/cacti CentOS 5 monitoring 
> box.
> 
> But priorities is a newbie thing? A default thing?  If it were default (and 
> it's been so long since I've used anything default that it might be and I 
> don't know it) and a default set of priorities were provided (or a very 
> conspicuous notice with the repository setup stating that priorities needs to 
> be set up before using the repo) then perhaps it might be a useful newbie 
> solution.

But priorities/weighing/protectbase and all filtering
selective/partial enabling of repos is creating worse per-user bugs
than it is supposed to fix. Think it through or google for
selective/partial enablement of repos.

Or paraphrased: You can't have a technical soultion for a inter-human
problem. If the packagers don't talk to each other in a forthcomming
way then you can have some depsolver be intelligent enough to avoid
breakage.

After having hunted down about a hundred red herring bugs due to such
priorities and the like settings ATrpms' official position is that you
are on your own if you start using them and something breaks.

Having said that ATrpms (and rpmrepo.org) does offer replacement-free
subrepos (currently only for RHEL5) so that you can have a choice w/o
relying on messy client-side filtering. Of course this only affect
Fedora/RHEL proper and not every other 3rd party repo out there.

I do wish we would have had the very big merger, indeed ... :(
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080120/187be90e/attachment-0001.sig>


More information about the fedora-list mailing list