Do we need rpmfusion-unstable repositories ?

Nicolas Chauvet (kwizart) kwizart at gmail.com
Sat Oct 11 11:15:14 CEST 2008


Just with my previous message. I've suggested the need of having the
nvidia beta driver provided from a separate repository.

Actually there are others cases where it would be needed:
-vlc is now at 0.9.x but still has very hard regression (VLM, vlvc,
interaction with dependents software) from 0.8.6x, which last is
officially unsupported (despite the unreleased 0.8.7 version is here to
collect patches).
- ieee1394 stack is still needed for some driver like
http://www.ffado.org/ (it may also need compat-libraw1394 unless the
dual stack mode works).
- Experimental packages (that do not fit Fedora guideline yet) could
benefit to be widely distributed. (I'm think of freevo from my personal
repository right now, which isn't ready for review yet).
- Might be other needs...

For theses needs, the current design of the rpmfusion repositories
doesn't provide a solution yet.

So this repository could be defined as such:
- Reserved for developers, experienced users, adviced users.
- What unstable means here isn't only beta software, but also
  * software that was not qualified as stable on a given "Fedora ABI
freeze", thus can lead to packages interaction problem. (vlc updated to
0.9.x / libraries such as ffmpeg with ABI/API bump for testing before to
update in rpmfusion-stable).
  * Technology choices not keepted (ieee1394/juju) but still having
regression for some special use (ffado)
- Repository shouldn't be activated by default in any case (no kmod for
all kernels will be garanted, so better to use akmod ).
- Users shouldn't use "wide update" but only targeted update.
 (like yum update --enablerepo=rpmfusion-unstable xorg-x11-drv-nvidia)
- Package replacement could be allowed from either Fedora/RPMFusion but
should be prevented for "long term"/or common use, specially when an
alternative solution is possible.
- Repository requirement will be unsorted but may needs dependencies
with fedora only, rpmfusion_free and rpmfusion_nonfree.
 (there will not be an unstable repository for each possibility of
interaction).

- Do you see others case where it would be needed?
- It it doable to implement cleanly on the buildsys?
(I May try to help at the admin level if needed).

 IMO it doesn't matter to have it ready to open rpmfusion (if even we
are ready). So there is no timeline for this feature. But it could be at
least discussed.

Nicolas (kwizart)



More information about the rpmfusion-developers mailing list