Hi,
I've read at Centos Wiki that "ts not possible to contribute a package into the CentOS Mirrors at this time. The entire process and policy around this matter is under review."
I'd like to submit a RPM package to CentOS, is that impossible still?
Thanks in advance!
On Tue, Apr 5, 2011 at 10:58 AM, Sergio Belkin sebelk@gmail.com wrote:
Hi,
I've read at Centos Wiki that "ts not possible to contribute a package into the CentOS Mirrors at this time. The entire process and policy around this matter is under review."
I'd like to submit a RPM package to CentOS, is that impossible still?
Thanks in advance!
--
submit it to fedora-epel
On Tue, Apr 5, 2011 at 6:58 AM, Sergio Belkin sebelk@gmail.com wrote:
I'd like to submit a RPM package to CentOS, is that impossible still?
Which package is it? There are some "external" people contributing packages to centos-[extras/plus] as I understand it, but there is not a good process for acceptance. Many people instead choose to contribute to EPEL (disclaimer, I am one of them) -- for better or for worse, but it might be something that makes more sense in your case.
-Jeff
On Tuesday 05 April 2011 16:58:01 Sergio Belkin wrote:
Hi,
I've read at Centos Wiki that "ts not possible to contribute a package into the CentOS Mirrors at this time. The entire process and policy around this matter is under review."
I'd like to submit a RPM package to CentOS, is that impossible still?
Thanks in advance!
You can always create your own repository and include it on your servers.
Regards, Marian
You can always create your own repository and include it on your servers.
Regards, Marian
don't do this.
contribute to fedora-epel, other people can use your packages and help testing / maintaining it.
------------
Itamar Reis Peixoto msn, google talk: itamar@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG)
On Tue, Apr 5, 2011 at 7:21 AM, Itamar Reis Peixoto itamar@ispbrasil.com.br wrote:
You can always create your own repository and include it on your servers.
Regards, Marian
don't do this.
contribute to fedora-epel, other people can use your packages and help testing / maintaining it.
In the case where you are over-writing/updating a core (or popular) package, then creating your own repository can make sense. If you are adding a new package which isn't already in CentOS or one of the popular 3rd party repos, then contributing it to an existing repo is usually better.
-Jeff
I may be wrong, but I am pretty certain Fedora want you to host it in your own repo during the QA stages for EPEL.
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org] On Behalf Of Itamar Reis Peixoto Sent: 05 April 2011 15:21 To: The CentOS developers mailing list. Subject: Re: [CentOS-devel] submit a RPM
You can always create your own repository and include it on your
servers.
Regards, Marian
don't do this.
contribute to fedora-epel, other people can use your packages and help testing / maintaining it.
------------
Itamar Reis Peixoto msn, google talk: itamar@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Visit Snell at NAB 2011 Booth N1820 http://www.snellgroup.com/campaign/nab2011
This email and any attachments are confidential, may be legally privileged and are intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.
Snell Limited, registered number 1160119 Registered in England, registered office at Hartman House, Danehill, Lower Earley, Reading, Berkshire RG6 4PB
Dne 5.4.2011 16:33, Chris Cowley napsal(a):
I may be wrong, but I am pretty certain Fedora want you to host it in your own repo during the QA stages for EPEL.
You are wrong http://download.fedora.redhat.com/pub/epel/beta/6/
Matěj
On 04/05/2011 02:58 PM, Sergio Belkin wrote:
Hi,
I've read at Centos Wiki that "ts not possible to contribute a package into the CentOS Mirrors at this time. The entire process and policy around this matter is under review."
I'd like to submit a RPM package to CentOS, is that impossible still?
Thanks in advance!
The process is still under review really, and ideally we would only want to accept packages from people where they are a part of ( or have commit access ) to the upstream for the code.
Aim being to involve stakeholders in both direction rather than create a packagers cloud.
- KB
2011/4/5 Karanbir Singh mail-lists@karan.org:
On 04/05/2011 02:58 PM, Sergio Belkin wrote:
Hi,
I've read at Centos Wiki that "ts not possible to contribute a package into the CentOS Mirrors at this time. The entire process and policy around this matter is under review."
I'd like to submit a RPM package to CentOS, is that impossible still?
Thanks in advance!
The process is still under review really, and ideally we would only want to accept packages from people where they are a part of ( or have commit access ) to the upstream for the code.
Aim being to involve stakeholders in both direction rather than create a packagers cloud.
- KB
If I undertand well, package it must be in upstream ie RH to be included in the official repo distro, mustn't it?
Greets.
On Wed, Apr 6, 2011 at 8:49 AM, Sergio Belkin sebelk@gmail.com wrote:
2011/4/5 Karanbir Singh mail-lists@karan.org:
On 04/05/2011 02:58 PM, Sergio Belkin wrote:
Hi,
I've read at Centos Wiki that "ts not possible to contribute a package into the CentOS Mirrors at this time. The entire process and policy around this matter is under review."
I'd like to submit a RPM package to CentOS, is that impossible still?
Thanks in advance!
The process is still under review really, and ideally we would only want to accept packages from people where they are a part of ( or have commit access ) to the upstream for the code.
Aim being to involve stakeholders in both direction rather than create a packagers cloud.
- KB
If I undertand well, package it must be in upstream ie RH to be included in the official repo distro, mustn't it?
Greets.
https://fedoraproject.org/wiki/PackageMaintainers
On 04/06/2011 12:49 PM, Sergio Belkin wrote:
The process is still under review really, and ideally we would only want to accept packages from people where they are a part of ( or have commit access ) to the upstream for the code.
If I undertand well, package it must be in upstream ie RH to be included in the official repo distro, mustn't it?
No. It means that we want the actual project commit'ers to get involved. eg. if mariadb was to be added into extras, someone who is a developer with commit access in the mariadb project would need to get involved. Similarly for postgresql, if there was to be a postgresql 9 in centosplus, it would need to come through with some level of 'stake ownership' from within that project. These are just two examples, hopefully clearing up the situation. If there is still some confusion, ask and I will try again.
In many cases, packagers are not close enough to the upstream project to ensure continuity and sync in both directions. Also, there already exist quite a few resources for 'packagers' to get involved into.
imho, and this is my personal opinion, not that of the CentOS Project : we should only open up to packager driven[1] rpm contributions if there is a real problem to be solved by doing that.
- KB
[1]: as opposed to project driven contributions ( of-course, in many cases its the same person or the same set of people. But creating that clear differentiation is important in this context )
On 4/6/2011 7:58 AM, Karanbir Singh wrote:
On 04/06/2011 12:49 PM, Sergio Belkin wrote:
The process is still under review really, and ideally we would only want to accept packages from people where they are a part of ( or have commit access ) to the upstream for the code.
If I undertand well, package it must be in upstream ie RH to be included in the official repo distro, mustn't it?
No. It means that we want the actual project commit'ers to get involved. eg. if mariadb was to be added into extras, someone who is a developer with commit access in the mariadb project would need to get involved. Similarly for postgresql, if there was to be a postgresql 9 in centosplus, it would need to come through with some level of 'stake ownership' from within that project. These are just two examples, hopefully clearing up the situation. If there is still some confusion, ask and I will try again.
In many cases, packagers are not close enough to the upstream project to ensure continuity and sync in both directions. Also, there already exist quite a few resources for 'packagers' to get involved into.
imho, and this is my personal opinion, not that of the CentOS Project : we should only open up to packager driven[1] rpm contributions if there is a real problem to be solved by doing that.
Are there any guidelines as to what should be in centosplus as opposed to some third party repo usable by RHEL, centos, and other rebuilds? And if they are more current versions of something included in the base distro, whether they should replace the stock package or be an alternatively-named package that can co-exist - or if both approaches are permitted, what guidelines would be used for the choice.
On 04/06/2011 04:56 PM, Les Mikesell wrote:
Are there any guidelines as to what should be in centosplus as opposed to some third party repo usable by RHEL, centos, and other rebuilds?
Do we need to have a policy about other repo's :) I guess the only policy might be : let them do what they think is right for them.
And if they are more current versions of something included in the base distro, whether they should replace the stock package or be an alternatively-named package that can co-exist - or if both approaches are permitted, what guidelines would be used for the choice.
Anything that replaces anything in the distro would goto CentOSPlus, everything else goes to Extras/ or Contrib/; pkgs in CentOSPlus can depend on Extras/ or Contrib/ but not the other way around.
Not everything can exist in multiple versions, in a parallel install - if there is something that can, then the choice to use <name><significatver> in %{name} is ok. eg. We do that with drbd at the moment.
- KB
On 4/6/2011 4:47 PM, Karanbir Singh wrote:
On 04/06/2011 04:56 PM, Les Mikesell wrote:
Are there any guidelines as to what should be in centosplus as opposed to some third party repo usable by RHEL, centos, and other rebuilds?
Do we need to have a policy about other repo's :) I guess the only policy might be : let them do what they think is right for them.
Other repo's _may_ respect upstream and not overwrite base packages or create conflicts. However, they aren't going to consider CentOS "upstream". And I think there is evidence that what is right for them is not going to be right for Centos users that have base/extra/plus packages that don't match or conflict with what they consider upstream.
So, yes, unless you want to ensure conflicts with the repos that CentOS users depend on, you need a policy that minimizes collisions. Personally, I don't see the point of having anything in a CentOS-specific repo that would be equally usable on RHEL, SL, etc., and having it there will set up a likely conflict with an EPEL or Rpmforge version unless they are maintained in sync. Things that use the extra features of the centosplus kernel would be an obvious exception and there are probably others.
On 04/06/2011 11:58 PM, Les Mikesell wrote:
Other repo's _may_ respect upstream and not overwrite base packages or create conflicts. However, they aren't going to consider CentOS "upstream". And I think there is evidence that what is right for them is not going to be right for Centos users that have base/extra/plus packages that don't match or conflict with what they consider upstream.
For a lot of these packages, there does not need to be an upstream concept if its project to project delivered. The centos.org repo's become a delivery mechanism to the centos userbase for a specific app in sync with what that app developers consider as their own policy ( and we can help them with the centos side of things )
So, yes, unless you want to ensure conflicts with the repos that CentOS users depend on, you need a policy that minimizes collisions.
There is very little or no coordination between repo's - and honestly, the only real issue we'd be looking to solve would be for the centos userbase, not SL/RHEL/anyone-else. And its unlikely to be a mass package dump.
Regards,
- KB
On 4/6/11 6:09 PM, Karanbir Singh wrote:
Other repo's _may_ respect upstream and not overwrite base packages or create conflicts. However, they aren't going to consider CentOS "upstream". And I think there is evidence that what is right for them is not going to be right for Centos users that have base/extra/plus packages that don't match or conflict with what they consider upstream.
For a lot of these packages, there does not need to be an upstream concept if its project to project delivered. The centos.org repo's become a delivery mechanism to the centos userbase for a specific app in sync with what that app developers consider as their own policy ( and we can help them with the centos side of things )
I'm not sure why an app developer would think a specialized package exclusively for CentOS would be desirable - and that idea seems like a particularly hard sell when the only goal for CentOS is binary compatibility with upstream.
So, yes, unless you want to ensure conflicts with the repos that CentOS users depend on, you need a policy that minimizes collisions.
There is very little or no coordination between repo's - and honestly, the only real issue we'd be looking to solve would be for the centos userbase, not SL/RHEL/anyone-else. And its unlikely to be a mass package dump.
The lack of coordination is exactly my point. Unless you can provide every package that CentOS users will ever need, it becomes very likely that there will be people solving that same problem for RHEL/SL/etc. with packages with the same name, leapfrogging version numbers, and different and incompatible compile/config options in another repository that many CentOS users will need to have installed and active. Maybe CentOS- could be part of the package name, but filename conflicts would still happen.
-- Les Mikesell lesmikesell@gmail.com
On 04/07/2011 02:09 AM, Les Mikesell wrote:
I'm not sure why an app developer would think a specialized package exclusively for CentOS would be desirable - and that idea seems like a particularly hard sell when the only goal for CentOS is binary compatibility with upstream.
There is a lot of stuff that is distro specific out there, eg. cloud services; besides lets not try and solve the problems for all the various app projects out there. The aim is to create a process and resource pool behind that process / policy. Leave it to the vendors to see if they want to make the effort inbound.
Going by the fact that I have over a dozen request-for-more-info in my inbox since this thread started, I feel there is definitely something to be done.
- KB
On Wed, 6 Apr 2011, Les Mikesell wrote:
Personally, I don't see the point of having anything in a CentOS-specific repo that would be equally usable on RHEL, SL, etc., and having it there will set up a likely conflict with an EPEL or Rpmforge version unless they are maintained in sync. Things that use the extra features of the centosplus kernel would be an obvious exception and there are probably others.
I would even vote for not picking up anything other than what upstream is doing. I much rather have more timely releases and updates, fastrack, and maybe other RHN channels (eg. EAL), than using those resources for extracurricular activities like DRBD packages, a centosplus kernel, etc...
ELRepo is pretty much the place nowadays for additional kernel modules, kernel functionality and kernels. And there's RPMforge and EPEL that allow contributions.
On Wed, Apr 6, 2011 at 6:20 PM, Dag Wieers dag@wieers.com wrote:
On Wed, 6 Apr 2011, Les Mikesell wrote:
Personally, I don't see the point of having anything in a CentOS-specific repo that would be equally usable on RHEL, SL, etc., and having it there will set up a likely conflict with an EPEL or Rpmforge version unless they are maintained in sync. Things that use the extra features of the centosplus kernel would be an obvious exception and there are probably others.
I would even vote for not picking up anything other than what upstream is doing. I much rather have more timely releases and updates, fastrack, and maybe other RHN channels (eg. EAL), than using those resources for extracurricular activities like DRBD packages, a centosplus kernel, etc...
+1 Diversify only if you have the resources. Or, if you can bring them on-board if you don't have them.
jerry
On 04/07/2011 02:48 AM, Jerry Amundson wrote:
Diversify only if you have the resources. Or, if you can bring them on-board if you don't have them.
Absolutely, the present system we have in place is exceptionally painful to use for such things; one of the reasons why its moving to an all-change for the c6 builds. But resource is more than just the buildsystem and services around it - its also about people and traction in the community, and thats one reason I'm very keen on getting this list ( centos-devel ) more active and get more people's eyes on things going on here.
- KB
-
Chris Cowley -
Dag Wieers -
Itamar Reis Peixoto -
Jeff Sheltren -
Jerry Amundson -
Karanbir Singh -
Les Mikesell -
Marian Marinov -
Matej Cepl -
Sergio Belkin