[suggest] Gnome 2.32 backported to RHEL6

[Sergio Rubio]

Hi all,

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.

Regards.
--
Sergio Rubio

FrameOS Linux
http://www.frameos.org
twitter: @rubiojr
blog: http://blog.frameos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101126/b125bcfc/attachment.html

[Dag Wieers]

Post by Sergio Rubio
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.

[Sergio Rubio]

Post by Sergio Rubio
I've backported Gnome 2.32 packages to RHEL6 and I wonder if they could

Post by Sergio Rubio
have
a place in RPMForge instead of keeping them in my own repos.

Hi Sergio,

Hey Dag,

Post by Sergio Rubio
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/

Post by Sergio Rubio
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101126/7caaa294/attachment.html

[Gerd v. Egidy]

Hi Sergio and Dag,

Post by Sergio Rubio

Post by Dag Wieers
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

[Gerd v. Egidy]

Hi Sergio and Dag,

Post by Sergio Rubio

Post by Dag Wieers
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

[Gerd v. Egidy]

Hi Sergio and Dag,

Post by Sergio Rubio

Post by Dag Wieers
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

[Gerd v. Egidy]

Hi Sergio and Dag,

Post by Sergio Rubio

Post by Dag Wieers
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

[Gerd v. Egidy]

Hi Sergio and Dag,

Post by Sergio Rubio

Post by Dag Wieers
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

[Sergio Rubio]

Post by Sergio Rubio
I've backported Gnome 2.32 packages to RHEL6 and I wonder if they could

Post by Sergio Rubio
have
a place in RPMForge instead of keeping them in my own repos.

Hi Sergio,

Hey Dag,

Post by Sergio Rubio
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/

Post by Sergio Rubio
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101126/7caaa294/attachment-0001.html

[Sergio Rubio]

Post by Sergio Rubio
I've backported Gnome 2.32 packages to RHEL6 and I wonder if they could

Post by Sergio Rubio
have
a place in RPMForge instead of keeping them in my own repos.

Hi Sergio,

Hey Dag,

Post by Sergio Rubio
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/

Post by Sergio Rubio
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101126/7caaa294/attachment-0002.html

[Sergio Rubio]

Post by Sergio Rubio
I've backported Gnome 2.32 packages to RHEL6 and I wonder if they could

Post by Sergio Rubio
have
a place in RPMForge instead of keeping them in my own repos.

Hi Sergio,

Hey Dag,

Post by Sergio Rubio
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/

Post by Sergio Rubio
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101126/7caaa294/attachment-0003.html

[Sergio Rubio]

Post by Sergio Rubio
I've backported Gnome 2.32 packages to RHEL6 and I wonder if they could

Post by Sergio Rubio
have
a place in RPMForge instead of keeping them in my own repos.

Hi Sergio,

Hey Dag,

Post by Sergio Rubio
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/

Post by Sergio Rubio
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20101126/7caaa294/attachment-0004.html>

[Sergio Rubio]

Hi all,

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.

Regards.
--
Sergio Rubio

FrameOS Linux
http://www.frameos.org
twitter: @rubiojr
blog: http://blog.frameos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101126/b125bcfc/attachment-0001.html

[Dag Wieers]

Post by Sergio Rubio
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.

[Sergio Rubio]

Hi all,

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.

Regards.
--
Sergio Rubio

FrameOS Linux
http://www.frameos.org
twitter: @rubiojr
blog: http://blog.frameos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101126/b125bcfc/attachment-0002.html

[Dag Wieers]

Post by Sergio Rubio
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.

[Sergio Rubio]

Hi all,

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.

Regards.
--
Sergio Rubio

FrameOS Linux
http://www.frameos.org
twitter: @rubiojr
blog: http://blog.frameos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101126/b125bcfc/attachment-0003.html

[Dag Wieers]

Post by Sergio Rubio
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.

[Sergio Rubio]

Hi all,

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.

Regards.
--
Sergio Rubio

FrameOS Linux
http://www.frameos.org
twitter: @rubiojr
blog: http://blog.frameos.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20101126/b125bcfc/attachment-0004.html>

[Dag Wieers]

Post by Sergio Rubio
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.