To all:
Thank you for the links to grunt and the gurulabs presentation - I have not come across those before. Here's another toolset that I have just started exploring:
https://github.com/marquiz/git-buildpackage-rpm/
http://marquiz.github.io/git-buildpackage-rpm/gbp-rpm.html 

The idea is to build rpms from within your own git repo - a very handy thing indeed. Besides constructing custom rpms for third-party packages, or re-packaging others' srpms, I would like ultimately make it easy enough for developers to create rpms as a normal part of their build cycle for their own software. Of course, one needs to implement the local yum repo thing previously mentioned.

Tim

-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]] On Behalf Of Stephen John Smoogen
Sent: August 13, 2015 08:05
To: [log in to unmask]
Cc: [log in to unmask]
Subject: Re: What's the best way to learn RPM packaging?

On 13 August 2015 at 01:35, Phil Wyett <[log in to unmask]> wrote:

>> Hi Joe,
>>
>> I do not know if the following falls in the "no good" category but I 
>> used it a lot to learn how to build my own packages :
>>
>> http://www.rpm.org/max-rpm/
>>
>> JM
>>
>
> Hi,
>
> A decent reference is:
>
> https://fedoraproject.org/wiki/How_to_create_an_RPM_package
>
> Regards
>
> Phil
>
> --
> Twitter: @philwyett
> Jappix (xmpp chat): [log in to unmask]

Two other tools which are useful:

1) Look through existing RPMs that match what you are doing. If you have a bunch of perl or python or ruby looking at existing packages can help you figure out why the guidelines and what you are trying aren't working [because packaging is like cooking and sometimes you need a LOT MORE SALT.. or none at all.]

2) Worse comes to worse.. there is easy-rpm. This is the "I give up and I need something by the end of the day." solution. It is not pretty, won't win friends, and will probably not work 2 times the same way in a row.. but if you need it and it migth give you an idea on how to do it. https://www.npmjs.com/package/grunt-easy-rpm



--
Stephen J Smoogen.