Last week I tried moving to updates-testing in order to test latest KDE on F7. The resulting kernel update was mismatched with kernel-devel so I could not install the nvidia drivers. My suggestion is this. Would it be possible to segregate updates according to package type (similiar to the SUSE buildservice) or even just along the lines of Desktop (KDE/GNOME/etc and deps) and System( kernel etc.) so testing bleeding edge packages from one package group won't break other system packages?
Mark Bidewell
On Mon, 5 Nov 2007, Mark Bidewell wrote:
Last week I tried moving to updates-testing in order to test latest KDE on F7. The resulting kernel update was mismatched with kernel-devel so I could not install the nvidia drivers. My suggestion is this. Would it be possible to segregate updates according to package type (similiar to the SUSE buildservice) or even just along the lines of Desktop (KDE/GNOME/etc and deps) and System( kernel etc.) so testing bleeding edge packages from one package group won't break other system packages?
Not to derail your idea, but is this necessarily anything that `yum --enablerepo=updates-testing --exclude=kernel* upgrade` wouldn't fulfill? At this point my brain started muttering something about "hey, wouldn't a `yum groupupgrade` command be awesome?" Which led me to look at the yum man page...which fails me. It only has groupupdate. *sad panda* Seth, would `groupupgrade` be a simple add-on? Or just pointless? Not sure if obsoletes are important enough...
So yeah, in summary, I'm guessing `yum --enablerepo=updates-testing groupupdate "KDE (K Desktop Environment)"` will do what you want.
Jima
On Mon, 2007-11-05 at 08:47 -0600, Jima wrote:
On Mon, 5 Nov 2007, Mark Bidewell wrote:
Last week I tried moving to updates-testing in order to test latest KDE on F7. The resulting kernel update was mismatched with kernel-devel so I could not install the nvidia drivers. My suggestion is this. Would it be possible to segregate updates according to package type (similiar to the SUSE buildservice) or even just along the lines of Desktop (KDE/GNOME/etc and deps) and System( kernel etc.) so testing bleeding edge packages from one package group won't break other system packages?
Not to derail your idea, but is this necessarily anything that `yum --enablerepo=updates-testing --exclude=kernel* upgrade` wouldn't fulfill? At this point my brain started muttering something about "hey, wouldn't a `yum groupupgrade` command be awesome?" Which led me to look at the yum man page...which fails me. It only has groupupdate. *sad panda* Seth, would `groupupgrade` be a simple add-on? Or just pointless? Not sure if obsoletes are important enough...
what would groupupgrade do that groupupdate doesn't do? and more to the point, what is it you think groupupdate does?
-sv
Mea Culpa Yes I forgot about the group* commands that would do what I wanted. Thanks
On 11/5/07, Jima jima@beer.tclug.org wrote:
On Mon, 5 Nov 2007, Mark Bidewell wrote:
Last week I tried moving to updates-testing in order to test latest KDE
on
F7. The resulting kernel update was mismatched with kernel-devel so I
could
not install the nvidia drivers. My suggestion is this. Would it be possible to segregate updates according to package type (similiar to the SUSE buildservice) or even just along the lines of Desktop
(KDE/GNOME/etc
and deps) and System( kernel etc.) so testing bleeding edge packages
from
one package group won't break other system packages?
Not to derail your idea, but is this necessarily anything that `yum --enablerepo=updates-testing --exclude=kernel* upgrade` wouldn't fulfill? At this point my brain started muttering something about "hey, wouldn't a `yum groupupgrade` command be awesome?" Which led me to look at the yum man page...which fails me. It only has groupupdate. *sad panda* Seth, would `groupupgrade` be a simple add-on? Or just pointless? Not sure if obsoletes are important enough...
So yeah, in summary, I'm guessing `yum --enablerepo=updates-testing groupupdate "KDE (K Desktop Environment)"` will do what you want.
Jima-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 05.11.2007 15:24, Mark Bidewell wrote:
Last week I tried moving to updates-testing in order to test latest KDE on F7. The resulting kernel update was mismatched with kernel-devel so I could not install the nvidia drivers. My suggestion is this. Would it be possible to segregate updates according to package type (similiar to the SUSE buildservice) or even just along the lines of Desktop (KDE/GNOME/etc and deps) and System( kernel etc.) so testing bleeding edge packages from one package group won't break other system packages?
That's IMHO the wrong way forward.
The real solution is to build kmods in livna for testing. That is unlikely to happen. But it's my plan for rpmfusion, as we'll use the current Fedora push scripts there, which make dealing with a testing repo much easier.
CU knurd
-
Jima -
Mark Bidewell -
Seth Vidal -
Thorsten Leemhuis