Where we are and where do we what to go?

Michael Schwendt mschwendt at gmail.com
Mon Jan 26 19:04:59 CET 2009


On Mon, 26 Jan 2009 15:59:43 +0100, Thorsten wrote:

> On 26.01.2009 13:29, David Timms wrote:
> > Michael Schwendt wrote:
> >> On Mon, 26 Jan 2009 12:53:46 +0100, Thorsten wrote:
> >>
> >>>>>> - still lots of other 3rd party repos out there; users still run 
> >>>>>> into problems as they try to mix incompatible repos; should we 
> >>>>>> actively try to get more repos merged into RPM Fusion?
> >>>>> Yes!
> >>>> I haven't been on lists etc where users are having such trouble recently
> >>>> (actually one I did suggest going with RPM Fusion rather than a
> >>>> troublesome combination of 4 other external repos.
> >>> There was someone on fedora-list recently that had trouble, as he had 
> >>> atrpms and rpmfusion enabled.
> >> ffmpeg vs. ffmpeg-libs as well as x264 currently cause unresolved deps
> >> due to soname differences.
> > Do you think RPM Fusion packages should include conflicts or similar 
> > (with external 3rd party repos packaging) to stop an install that would 
> > cause the two styles of packaging to both be installed ?
> 
> I have thought about that as well since the recent discussion on 
> fedora-list (the one where mschwendt provided more details).
> 
> I tend to think it would be good to do. But OTOH: I fear that people 
> don't properly why it's done and we might be the bad guys from their 
> point of view.

Bad idea, IMO.

It's only possible to conflict with NEVR tuples, but not with repo ids.
If packages from different repos share some package names, you've lost.
Explicit "Conflicts" also cannot protect against unresolvable
dependencies.

The conflicts in ffmpeg/x264 apparently are older, btw, and reappear
during dependency resolving:

| http://dl.atrpms.net/all/ffmpeg.spec
|
| Obsoletes: ffmpeg-libs <= %{evr}
| %lib_dependencies
|
| * Sun Nov 16 2008 Axel Thimm <Axel Thimm ATrpms net> - 0.4.9-28_r15845
| - ffmpeg-libs from a 3rd party repo generates conflicts.



More information about the rpmfusion-developers mailing list