[packagers] becoming a packager

[J Robinson]

Hello, Dag;

thanks for the response. Here's a follow up question:

how do I setup an rpmforge/rpmrepo dev env? I suspect I need to fetch
the tree of spec files from svn and the source tarballs from somewhere
too.

There are two things I want to package into rpms at present: one comes
with a sample spec file which works, and one is a perl module.

On a related note, I noticed that  the current cpan2rpm distro doesn't
work (without mods) with the current version of Pod::Text (and is not
in rpmforge). Perhaps I should start by making a spec that fixes the
problem and building a working cpan2rpm rpm?

If you like, I'll combine and summarize this into a publishable document.

Looking forward to hearing back,
 jrobinson

On Nov 16, 2007 10:17 AM, Dag Wieers <dag at wieers.com> wrote:
>
> On Fri, 16 Nov 2007, J Robinson wrote:
>
> > I'm interested in becoming a packager, but I'm pretty new to building RPMs.
> >
> > How do I set up to become a rpmforge packager? I've rebuilt a few rpms
> > from src.rpms using rpmbuild but that's about it-- I want to
> > transition away from using scripts to install things from source
> > towards building custom RPMs and this seems like a good way to go.
> >
> > I noticed that the packager's info page is pretty minimal.... any tips
> > on how to get started? I'm looking at the archives now...
>
> First of all you need to know that RPMforge is in a transitional phase.
> The new project is called rpmrepo and is a merge of existing repositories
> (like atrpms, rpmforge, centos extras and more) but it is only slowly
> progressing with the infrastructure.
>
> So in the meantime RPMforge is chewing on as before, but the website was
> never really maintained (and is mostly outdated). If you consider joining
> rpmrepo, your work with RPMforge is not lost, it will move to rpmrepo.
>
> Build RPM packages in itself is pretty straightforward, the hard part is
> knowing what works and what doesn't (that is the experience). My aim with
> RPMforge was to focus on SPEC file simplicity and consistency.
>
> This means that our SPEC files have a well-defined order and structure and
> we modify SPEC files to be consistent with that. I am writing a document
> that explains all these items, but most of the SPEC files in the
> repository (and especially the recently updated ones) comply to these
> (mostly) unwritten rules.
>
> The strict structure is there to make it easier to maintain SPEC files in
> bulk which sometimes is necessary.
>
> So once you have created a SPEC file (see subversion for 4000+ examples),
> you can create a package from it with the rpmbuild command, eg:
>
>         rpmbuild -bb something.spec
>
> That is the basics. :) Any specific questions yet ?
>
> --
> --   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
> [Any errors in spelling, tact or fact are transmission errors]
>