FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 09-18-2010, 05:40 PM
Stephen John Smoogen
 
Default Conversations with centos-devel

I sent a ping a while back on putting in a weight of 2000 for EPEL-6
and the general consensus was that it did not matter to them what we
did. [More or less.] So I would say that when we update the
epel-release next time to put it in the epel.repo. [And make sure we
announce it for partners.]

--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 09-18-2010, 06:10 PM
Paul Howarth
 
Default Conversations with centos-devel

On Sat, 18 Sep 2010 11:40:28 -0600
Stephen John Smoogen <smooge@gmail.com> wrote:

> I sent a ping a while back on putting in a weight of 2000 for EPEL-6
> and the general consensus was that it did not matter to them what we
> did. [More or less.] So I would say that when we update the
> epel-release next time to put it in the epel.repo. [And make sure we
> announce it for partners.]

And if we do that, we should be able to clone RHEL Workstation packages
(the ones not in RHEL Server) and put them EPEL without causing issues
for RHEL Workstation users...

Shouldn't we?

Paul.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 09-19-2010, 06:29 PM
Jesse Keating
 
Default Conversations with centos-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/18/2010 11:10 AM, Paul Howarth wrote:
> On Sat, 18 Sep 2010 11:40:28 -0600
> Stephen John Smoogen <smooge@gmail.com> wrote:
>
>> I sent a ping a while back on putting in a weight of 2000 for EPEL-6
>> and the general consensus was that it did not matter to them what we
>> did. [More or less.] So I would say that when we update the
>> epel-release next time to put it in the epel.repo. [And make sure we
>> announce it for partners.]
>
> And if we do that, we should be able to clone RHEL Workstation packages
> (the ones not in RHEL Server) and put them EPEL without causing issues
> for RHEL Workstation users...
>
> Shouldn't we?
>

I'm of the opinion that we should still not do this, except for extreme
situations. EPEL was not meant to be an end-run around RHEL packages or
RHEL pricing, and while we could technically do it and have less chance
of hurting people's systems, I don't think EPEL is the place for that.
There is plenty of room for a slightly more removed repository from EPEL
where one could provide updated versions of packages.


- --
Jesse Keating
Fedora -- Freedom is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkyWVooACgkQ4v2HLvE71NXG/gCfbsbQuywNSVXOWsq8Z8MJk2rV
vbAAnionBvNavd0QrAKaV8OJRrmYfZIA
=OuCE
-----END PGP SIGNATURE-----

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 09-21-2010, 12:40 PM
Paul Howarth
 
Default Conversations with centos-devel

On 19/09/10 19:29, Jesse Keating wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/18/2010 11:10 AM, Paul Howarth wrote:

On Sat, 18 Sep 2010 11:40:28 -0600
Stephen John Smoogen<smooge@gmail.com> wrote:


I sent a ping a while back on putting in a weight of 2000 for EPEL-6
and the general consensus was that it did not matter to them what we
did. [More or less.] So I would say that when we update the
epel-release next time to put it in the epel.repo. [And make sure we
announce it for partners.]


And if we do that, we should be able to clone RHEL Workstation packages
(the ones not in RHEL Server) and put them EPEL without causing issues
for RHEL Workstation users...

Shouldn't we?



I'm of the opinion that we should still not do this, except for extreme
situations. EPEL was not meant to be an end-run around RHEL packages or
RHEL pricing, and while we could technically do it and have less chance
of hurting people's systems, I don't think EPEL is the place for that.
There is plenty of room for a slightly more removed repository from EPEL
where one could provide updated versions of packages.


Well let's suppose that when RHEL-6 comes out, there's no add-on
repository to provide Workstation packages for Server customers. Are you
suggesting that a server product like bugzilla, which has at least one
dependency on a Workstation-only package
(https://bugzilla.redhat.com/show_bug.cgi?id=626218) should be moved to
a "slightly more removed repository"? And where might that be?


Paul.

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 09-21-2010, 06:54 PM
Mark Chappell
 
Default Conversations with centos-devel

On 19 September 2010 20:29, Jesse Keating <jkeating@redhat.com> wrote:
> On 09/18/2010 11:10 AM, Paul Howarth wrote:
>> And if we do that, we should be able to clone RHEL Workstation packages
>> (the ones not in RHEL Server) and put them EPEL without causing issues
>> for RHEL Workstation users...
>>
>> Shouldn't we?
>>
>
> I'm of the opinion that we should still not do this, except for extreme
> situations. *EPEL was not meant to be an end-run around RHEL packages or
> RHEL pricing, and while we could technically do it and have less chance
> of hurting people's systems, I don't think EPEL is the place for that.
> There is plenty of room for a slightly more removed repository from EPEL
> where one could provide updated versions of packages.

Except that's not what we're talking about doing (the Fedora
discussion about recent versions of packages is separate). *If* there
is no "productivity" channel for Server then we're not talking about
bypassing the pricing scheme, we're talking about something that
people just plain can't get through Red Hat. Things like perl
packages which are in Workstation (b2 refresh) as dependencies for GUI
tools, but are used by server type services, eg RT, and which RHEL
Server doesn't provide.

The only time your argument hold up in this case is if there is a paid
for channel that provides the additional packages. At which point
we'll need to decide which channels we're targeting. What makes
things worse is that as RHEL becomes a more complex product, with more
bolt-ons and options, trying to create EPEL becomes more complex:
Exactly which combinations of channels and architectures are we aiming
to provide packages for?

With the perl tree this has become a nightmare, it was tough getting
things like RT in before when some packages were pinned to old
versions, but now you're suggesting that some we couldn't even have,
simply because a GUI happened to use it in RHEL Workstation?

However, at this point I am just going to say, let's wait until
details of how RHEL6 is going to be structured are public, so we can
at least make an informed decision and not do things that are going to
make Rel-Eng-EPEL's life difficult. If this means that there's going
to be a lag of a few weeks before EPEL is completely ready, post GA,
then that's life. If anyone wants to help get stuff ready, post GA
because they want to deploy ASAP well they can always help with the
EPEL effort, we are after all simply volunteers.


Mark

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 09-22-2010, 08:04 AM
"Xavier Bachelot"
 
Default Conversations with centos-devel

> At which point
> we'll need to decide which channels we're targeting. What makes
> things worse is that as RHEL becomes a more complex product, with more
> bolt-ons and options, trying to create EPEL becomes more complex:
> Exactly which combinations of channels and architectures are we aiming
> to provide packages for?

Maybe the question could be worded slightly differently : which channels
is CentOS targeting ? This is the only freely available tree to build
against and this is what the EPEL mock configs are pointing at.

Regards,
Xavier

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 07:43 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org