Axel Thimm wrote:
> And to xine: This is also a package by Paulo, so I can say less about
> it, but AFAIK he needed to undo some of the multimedia codec removal
> bits to reenable some functionality.
That's what xine-lib-extras-freeworld in RPM Fusion is for.
xine-lib has a plugin architecture, so adding features should be done by
adding the plugins, not replacing the whole package.
As for the conflicts with RPM Fusion, I don't think it is fair to blame it
all on RPM Fusion. There's a lot you could do to avoid both
incompatibilities and duplication of effort. Upgrade paths are not really a
convincing argument: it was no problem to ensure proper upgrade paths from
both Livna and FreshRPMs, I'm sure RPM Fusion maintainers will be willing
to fix the upgrade paths from ATrpms for the relevant packages if you
accept that RPM Fusion will be the authority for those packages. In fact
many of them will also have no problems with letting you and/or Paolo
comaintain those packages. The root of the problem is that you're shipping
some packages which are also in RPM Fusion. There would be no
incompatibility if you didn't do that.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
