[packagers] becoming a packager

[J Robinson]

Hello, Dag:

For starters, I want to use mock to build mediawiki rpms for centos5.
If I do 'mock --debug rebuild mediawiki-1.8.5-9.fc6.src.rpm', it fails
because the mediawiki BuildRequires says it needs ocaml.

OK. So I create a new   /etc/mock/centos-5-x86_64-rpmforge.cfg  ,
based on /etc/mock/centos-5-x86_64.cfg, and add the following lines
before the closing """:

[rpmforge]
name=rpmforge
baseurl=http://apt.sw.be/redhat/el5/en/$basearch/dag

and make /etc/mock/default.cfg a symlink to that file.

Then I run
mock --debug mediawiki-1.8.5-9.fc6.src.rpm

But both setups report the same thing:
Cannot find build req  ocaml >= 3.06. Exiting.

how do I enable the rpmforge repo inside mock's chroot?

Thanks,
jrobinson

On Nov 16, 2007 10:48 AM, Dag Wieers <dag at wieers.com> wrote:
>
> On Fri, 16 Nov 2007, J Robinson wrote:
>
> > 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 ?
> >
> > 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.
>
> Ok, there are 2 parts to building RPMs. The repository and the
> buildsystem, the repository is easy:
>
>         svn co http://svn.rpmforge.net/svn/trunk/rpms/
>
> The buildsystem is more complicated because some of us have their own
> system. But there is a more generic system that is probably where we all
> are heading to: mock
>
> With mock you have to set up (configure) for each distribution you want to
> use. These templates are available but often needs customising, which is
> bad :-( But others can help you with mock. (I am interested to learn what
> they have to say though)
>
>
> > 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.
>
> Ok, if you already have a SPEC file you can simply submit it to
> suggests at lists.rpmforge.net and we'll add validate and add it.
>
> Perl modules are different, since there are 13.000 perl module
> distributions, we have opted to semi-automate the process. I've send a
> mail to this list that you can find in the archives that explains how it
> works. To make the story short, just tell me the name of the module, and
> I'll generate and add it.
>
> We have no real plans to add all 13.000 perl packages (yet), we tend to
> focus on the ones that are actively maintained and the ones that are
> popular. The popular ones we have to learn from our userbase, the active
> ones we know because we follow to new releases. (although I am still busy
> updating the ones we already have, after that I'll commit myself to
> add new ones too)
>
>
> > 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?
>
> We do not use cpan2pm because the resulting SPEC file does not work on all
> distributions and we prefer a SPEC file that works on EL2, EL3, EL4 _and_
> EL5 over one SPEC file per distribution. (because that becomes quickly
> unmaintainable).
>
> We cherish the time of our volunteers :-)
>
>
> > If you like, I'll combine and summarize this into a publishable document.
>
> That would be very nice, maybe that belongs on the rpmrepo wiki. I would
> suggest you subscribe to the mailinglist at:
>
>         http://rpmrepo.org/mailman/listinfo/rpmrepo-devel
>
> Since you have no prior-knowledge you would be best suited to ask
> questions and document as you learn. (And people will want to explain it
> to you as good as possible since it will end up in the official document)
>
>
> Also a planet rpmrepo would be interesting, then you could write a blog
> article of your progress every once in a while. That would be an
> interesting read to everybody and will no doubt lead to nice dicussions as
> well.
>
> --
>
> --   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
> [Any errors in spelling, tact or fact are transmission errors]
>