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


 
 
LinkBack Thread Tools
 
Old 04-06-2011, 12:01 PM
Itamar Reis Peixoto
 
Default submit a RPM

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


--
------------

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
 
Old 04-06-2011, 12:58 PM
Karanbir Singh
 
Default submit a RPM

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 )
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-06-2011, 03:56 PM
Les Mikesell
 
Default submit a RPM

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.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-06-2011, 09:47 PM
Karanbir Singh
 
Default submit a RPM

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-06-2011, 10:58 PM
Les Mikesell
 
Default submit a RPM

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.

--
Les Mikesell
lesmikesell@gmail.com


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-06-2011, 11:09 PM
Karanbir Singh
 
Default submit a RPM

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-06-2011, 11:20 PM
Dag Wieers
 
Default submit a RPM

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.

--
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-07-2011, 01:09 AM
Les Mikesell
 
Default submit a RPM

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-07-2011, 01:48 AM
Jerry Amundson
 
Default submit a RPM

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-07-2011, 10:29 AM
Karanbir Singh
 
Default submit a RPM

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 03:55 PM.

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