Thorsten Leemhuis píše v Út 10. 02. 2009 v 10:14 +0100: > On 10.02.2009 09:57, Dan Horák wrote: > > Thorsten Leemhuis píše v Po 09. 02. 2009 v 19:58 +0100: > >> On 09.02.2009 14:28, Dan Horák wrote: > >>> Thorsten Leemhuis píše v Ne 08. 02. 2009 v 10:06 +0100: > >>>> On 04.02.2009 14:24, Rex Dieter wrote: > >>>>> Thorsten Leemhuis wrote: > >>>>>> On 04.02.2009 14:00, Rex Dieter wrote: > >>>>>>> Andrea Musuruane wrote: > >>>>>>> [...] > >>>>>>> In the meantime, I'll go adjust the wiki to move kde-redhat to the > >>>>>>> "compatible" section. :) > >>>>>> If RPM Fusion would have one big and/or multiple dedicated > >>>>>> experimental > >>>>>> repos, would kde-redhat then be interested into "merging" into RPM > >>>>>> Fusion? > >>>>> yes! > >>>> I'd like that to happen. What others think of the idea to start a > >>>> experimental area and do the first steps with kde-redhat like repos? > >>> I agree and would like join with some of my stuff. > >> Hmmm. kde-redhat is something special, so a dedicated repo for it makes > >> a lot of sense afaics. > >> But do you need to have your own dedicated experimental repo. Might a > >> general experimental repo be a better solution? Not sure myself, just > >> want to hear options... > > > > Oh, I was thinking that we are going to offer a merger for the personal > > or highly specialized repos into one experimental repo (if possible) > > that will use RPM Fusion's infrastructure. > > [...] > > When there should be multiple repos, then I would prefer to divide them > > by relation to Fedora/RPM Fusion (eg. experimental, backports) rather > > then by area (kde, mono, math, ...) > > A dedicated "math" repo like really is not needed -- those packages are > likely more suitable for a general experimental and/or staging repo. But > I guess some sort of spits by area will be needed -- I guess that (for > example) the kde-redhat users likely don't want to get highly > experimental graphics drivers from the same repo when they run yum-update. > > Or how would you solve that? Excludes and includepkgs statements in the > repo files are likely way to complicated...
I should have known it will be complicated, but let's try to categorize the possible stuff: - new packages => no conflicts with Fedora/RPM Fusion => 2 repos (stable + testing), stable enabled by default - existing packages - experimental - examples: codeblocks - backports - examples: - forwardports (new stable versions from Fedora into EL) - examples: zabbix (no rebase 1.4->1.6 planned due DB changes etc, but some users would appreciate to have the 1.6) - one repo for each category, disabled by default, user must manually enable the repo and pick the package he want to install or update - special cases like kde-redhat - 2 repos (again stable + testing) per case, stable enabled by default Does this sound feasible? Dan