Re: [suggest] Gnome 2.32 backported to RHEL6
Hi Sergio and Dag, > > So anything build against RHEL6's gnome 2.32 may fail with a Gnome 2.32 > > backport and our aim is to break the least. But while I am personally not > > in favor of adding this to RPMforge I would like to have such a > > discussion because I think its merit is defining the rules or finding > > alternatives. > > But what about having RPMForge-Gnome and RPMForge-KDE (or > RPMForge-Desktop) with non server-centric desktop packages? I think separating this from the main rpmforge repo is a good idea. But the question I see is which repos to create. I fear that we create a separate repo for each group of applications (like rpmforge-gnome and rpmforge-kde) we will end up with lots of different repos. This will lead to confusion, incompatibility and lots of work to keep it maintained. Wouldn't it make more sense to have one seprate repo for all these non-leaf updates? We could call it rpmforge-nonleaf, -replace, -extra-extras or the like. I think such a repo makes sense for more than just gnome or kde. I have e.g. updated php for my centos 5 servers because we needed some features and fixes only available in the current versions. I kept them in my local repo but having such a repo in rpmforge would make it easy to publish it. Kind regards, Gerd -- Address (better: trap) for people I really don't want to get mail from: jo...@cactusamerica.com ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Gnome 2.32 backported to RHEL6
On Fri, Nov 26, 2010 at 12:57 PM, Dag Wieers wrote: > On Fri, 26 Nov 2010, Sergio Rubio wrote: > > I've backported Gnome 2.32 packages to RHEL6 and I wonder if they could >> have >> a place in RPMForge instead of keeping them in my own repos. >> > > Hi Sergio, > Hey Dag, > > The rules for RPMforge Extras are not really defined, but in the past we > always refrained from adding non-leaf packages into RPMforge. The reasoning > mainly is that if you replace too much from RHEL6, you no longer are running > RHEL6. > Makes perfect sense. I thought about this before backporting, and I came to the conclusion that while Fedora is the 'de facto' Red Hat Desktop distribution, some of us feel comfortable using what we use daily in our datacenters. So I explored the idea of backporting and I found that non of the 'core' components need to be replaced. Most of the stuff is related to Gnome and its dependencies: http://mirror.frameos.org/frameos/6/experimental/x86_64/Packages/ > > So anything build against RHEL6's gnome 2.32 may fail with a Gnome 2.32 > backport and our aim is to break the least. But while I am personally not in > favor of adding this to RPMforge I would like to have such a discussion > because I think its merit is defining the rules or finding alternatives. > Absolutely. I don't think merging G2.32 packages with existing RPMForge is a good idea either. But what about having RPMForge-Gnome and RPMForge-KDE (or RPMForge-Desktop) with non server-centric desktop packages? RPMForge packages would be isolated from the noise and we could build desktop packages on top of RPMForge/CentOS ones. Regards. -- Sergio Rubio FrameOS Linux http://www.frameos.org twitter: @rubiojr blog: http://blog.frameos.org ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
Re: [suggest] Gnome 2.32 backported to RHEL6
On Fri, 26 Nov 2010, Sergio Rubio wrote: I've backported Gnome 2.32 packages to RHEL6 and I wonder if they could have a place in RPMForge instead of keeping them in my own repos. Hi Sergio, The rules for RPMforge Extras are not really defined, but in the past we always refrained from adding non-leaf packages into RPMforge. The reasoning mainly is that if you replace too much from RHEL6, you no longer are running RHEL6. So anything build against RHEL6's gnome 2.32 may fail with a Gnome 2.32 backport and our aim is to break the least. But while I am personally not in favor of adding this to RPMforge I would like to have such a discussion because I think its merit is defining the rules or finding alternatives. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ suggest mailing list suggest@lists.rpmforge.net http://lists.rpmforge.net/mailman/listinfo/suggest
