.spec file for rhel6 rpm, with some config related patches

[djzort]

I created an rpm for rhel6 (which should be aok for centos6 and sl6 as well) so felt like it might be nice to send it through.

I made some config choices which i applied via some patches. That is apache2 (which is all thats available on el6) and postgresql with single mode.

database testing didnt work, so i just sort of carved that out of the build process.

also the dependencies are probably over the top and i turned off the make test part of the build process.

so im summary, not perfect by any means. i have made some choices in the .spec file as to how bricolage will be configured which people may not like... but perhaps someone will find it useful!

[theory]

Hey, thanks, this looks pretty good. I've been creating a lot of RPMs at work, so actually know how this shit works now. Sort of.

Anyway, a few questions:

• Why use the m install style? I would think most folks would prefer stuff not to be scattered around the system. Unless you were putting the DB, start script, and config files in RedHat-specific locations, but it doesn't look like it.
• I think it makes sense to support Apache 2 by default in the next major release. I suggest changing standard to default to that.
• Why the patches to have db.pl and db_grant.pl exit early? The grants, in particular, need to happen.
• Are all of the prereqs now provided by the RedHat or EPEL yum repositories? In other words, are any of those prereqs likely to lead to an install failure because they are not available?
• What do you have against the PHP and MySQL support? (Other than the obvious, I mean.)
• Maybe we should have a single directory for packaging files like this. So rather than redhat/perl-bricolage.spec, maybe it should be dist/perl-bricolage.spec?
• Also, does it need to have the perl- prefix? The fact that it is written in Perl is (hopefully) not important to most folks.

Thanks, this is a big help!

David

[djzort]

hi David

I put this together based on my own use case, which allowed for shortcuts. 'm' was appropriate for myself and can easily be changed for a 'canonical' rpm package.

In my use case I was upgrading from an earlier release that was installed without an rpm. I didnt want to spend the time to have the rpm populate (in my case) postgresql or have to deal with upgrading the schema. So yeah my usage had use of postgresql and no use of php.

I used cpanspec to create the rpm .spec file boilerplate. Bless its heart it tried, but was confused by a number of things which necessitated forcing all the dependencies. This also explains the perl- prefix.

I also used koji to built the rpm, and the tests had trouble in a 'mock' chroot - specifically starting up postgres etc.

As bricolage has so many options, you could either create a "mega" rpm which would drag in php, oracle, both postgres and mysql etc or perhaps rpms for a number of common flavor combos. Alas i am not skilled enough with .spec files to know how to implement these options as something you can select.

Ultimately, despite the decisions ive made in the .spec file which pertain to my usage case - i wanted to share the .spec file in the hope that more experienced RPMers would be able to refine it more (and i would learn something in the process)

[theory]

Hi djzort. Thanks for the detailed response!

• Yeah, let's make it an "m" install for the general use/release.
• You should be able to run make test without the database. It runs only a subset of the tests, unlike make devtest.
• I wasn't saying that the RPM should require Oracle, MySQL, and PHP. Rather, I think it should include the Oracle, PHP, and MySQL modules, just as it includes the Pg module. Maybe later we could remove PostgreSQL, too, and add packages for each database back, as well as some of the other optional stuff. So we'd end up with bricolage-pg, bricolage-mysql, bricolage-php, bricolage-tt, etc. See sqitch.spec for examples of such separate RPMs for different database support for Sqitch.
• Still not sure what's with the patches to db.pl and db_grant.pl. Can you enlighten me?
• Are you relying on EPEL for some of the prereqs?

If you are not able to do more at this point, I understand. I just don't know when anyone else will get to it either. One needs access to a box with the proper upstream Yum repos configured in order to even test it. I don't doubt this will be a big help bootstrapping such a project, though.

Thanks!

David

[djzort]

There are a lot of dependencies that are outside of stock el6 (be that centos6 or rhel6) and epel. So even a good .spec file will give people depedency hell. Would it be possible for bricolage to adopt Dist::Zilla? then cpansec will have a much nicer time creating boiler plate .spec code.

[theory]

I don't understand. You've already created the spec file. Now we can just edit it.

[phillipadsmith]

Not sure what the next action is here... @theory?

[theory]

@phillipadsmith Nothing, unless you want to take a stab at writing a distributable spec file.

[phillipadsmith]

@theory Unlikely, so closing for now.