[elrepo-devel] Contributions

[Phil Perry]

On 13/01/12 16:15, Nelson Marques wrote:
> No dia Sexta-feira, 13 de Janeiro de 2012, Phil Perryphil at elrepo.orgescreveu:
>
>> On 13/01/12 00:29, Nelson Marques wrote:
>>> Hi all,
>>>
>>> I'm a Enterprise Linux user and I do maintain a few a packages for
>> personal
>>> usage (and I'm also a casual client from a few kernel modules on ELREPO).
>>> What would be the best way to submit a few packages?
>>>
>>> NM
>>>
>>
>> Hi Nelson,
>>
>> Welcome to elrepo.
>>
>> There are a number of ways you can contribute depending upon your
>> experience and how involved you wish to get:
>>
>
> Hi Phil,
>
> Well, I'm far from being the supra-sumo packager and most of my experience
> is actually around (open)SUSE Linux where I maintain a few packages and
> projects, though more oriented to the GNOME Desktop Environment.
>
> I don't have extensive experience for Fedora/RHEL as a packager (though I
> do work with it for the past 12 years), but I think I can manage :)
>
>

Great, and we are more than willing to provide help/guidance where 
needed :-)

>>
>> 1. You could put in an RFE request at elrepo.org/bugs and ask one of the
>> existing packagers/developers to pick up the package.
>>
>> 2. You could develop/maintain the package yourself and contribute it via
>> our github repository and have one of the developers build and sign it
>> for you and push it into the repo. See here:
>>
>> https://github.com/elrepo/packages/
>>
>> 3. Finally you could become an elrepo developer, and build/maintain the
>> package yourself on the elrepo build systems, then only requiring an
>> elrepo admin to sign and push the finished packages.
>>
>> All of which hopefully provides enough options to suit most needs.
>>
>
> As long as reviews/commits are done in less time than EPEL, that's cool
> with me.
>
>

We try to turn stuff around as quickly as possible, of course keeping in 
mind that there are only a few of us doing any real packaging and we all 
do it purely on a voluntary basis outside of our day jobs etc.

Generally and WRT the above scheme, the more work you are prepared to 
take on as a contributor, and hence the less work it generates for us 
(me), the more successful you are likely to be. For example, if you 
select route #1 above then your proposed package not only has to fit the 
criteria of elrepo but also has to attract the interest of an elrepo 
developer to actually take it on and most of us already have more 
packages than we can reasonably maintain so if it looks like a lot of 
work then the number of takers will probably dwindle accordingly.

>
>
> Another question, for example, I would like to submit an updated package of
> DAHDI (system space and userland) which is somehow more complete than the
> current that you offer and has been properly tested. As some might be
> aware, this kernel module is used by Asterisk (either to load hardware
> drivers or a dummy/pseudo software driver). Your current package has a few
> nasty flaws which I can point:
>
>   * It doesn't provide the udev rules which has a dreadful impact on the
> system: devices are created owned by root:root and using 0600 permissions,
> which makes it rather unusable with Asterisk. It should be owned by user
> 'asterisk' and group 'asterisk' and created with permissions 0660 (upstream
> default). If people want to use it for the pseudo driver, there's a huge
> change it's not gonna work 'out of the box' without some tinkering (ex:
> hack the dahdi-tools sysv init scripts to change the permissions). If you
> use real hardware, you don't ship with the firmware, leading to another
> problem.
>
> Would an updated (2.4.1.2 for kmod and 2.4.1 for tools) package which
> provides a more complete set of options and which is actually according to
> Red Hat packaging rules (the current one does't offer the dahdi-kmod-common
> which is mandatory according to Fedora EPEL documentation) be of any
> interest?
>

Yes, definitely sounds of interest. Looking in the el5 tree I see we 
have dahdi 2.3 and it was packaged by my colleague Alan. Lets ask Alan 
what he has to say and see if he'd like to turn that package over to you 
to maintain going forward as you've expressed an interest in it.

WRT packaging guidelines, we are not Fedora nor are we EPEL. We do not 
aspire to adhere strictly to Fedora guidelines. We use Red Hat's Driver 
Update Programme framework present in RHEL as the basis for our kmod 
packages.

That said, we do generally try to follow Fedora packaging guidelines for 
best practice (for non-kmod packages), but kmods are handled very 
differently between Fedora and RHEL (Fedora has no stable kABI for 
example). One example of this difference is that we don't use a 
foo-kmod-common packaging format.

We have our own very specific templates for kmod packages for el5 and 
el6 that we would ask you to use as a starting point:

https://github.com/elrepo/templates

Generally the kmod package will provide little more than the kernel 
driver and minimal documentation. For larger packages that require 
additional user space tools etc, we would ship these in a separate 
accompanying package, such as is the case with dahdi, drbd, openafs etc, 
and we tend to deal with such matters on a case by case basis by 
discussion and consensus.

Feel free to look at any of our packages as examples of how we handle 
things and discuss here as necessary.


> I am ready to submit at least this package soon. I could submit to EPEL,
> but EPEL reviews take way too much time and I have a load of packages
> pending there.
>

Well lets see what Alan says about dahdi, and then we can work that 
package through the elrepo system which should give you a good feel for 
how we work and give you a pretty good idea if we are the kind of repo 
you are happy to contribute to, although please keep in mind that the 
first submission is probably always going to take the most time and 
going forwards things will hopefully only ever get faster as you get 
accustomed to our systems and procedures.