Ok, to make an RPM one should go through the steps to install the program manually using make etc. Joomla is a web based / php install. So, should I install this to a test dir using the php install then move that entire install to the /source dir?
Also, I'm sure during the setup it calls out to make an MySQL db and I see from the previous script that is setup in the app vault area which I can copy. Once I have the app moved to the source dir I need to tarball that and put it in the apps dir for the app vault dir structure yes?
Thanks.
Franklyn
RPM build / App Vault guidance / help questions.
-
Galactic Zero
- Forum Regular
- Posts: 471
- Joined: Mon Dec 06, 2004 10:43 pm
-
Galactic Zero
- Forum Regular
- Posts: 471
- Joined: Mon Dec 06, 2004 10:43 pm
Guess I didn't ask my question properly.
To build an RPM you first install the software, usually with make. Since Joomla is a PHP install, would I install that as normal and then move the installed dir's into my tarball for the source for the RPM?
I think I'm right but wanted some clarification. I know that the RPM will install the program based off how the configure and make and make install all work just wanted to be sure that was also how it was done for a program that doesn't install that way, like Joomla.
Thanks.
To build an RPM you first install the software, usually with make. Since Joomla is a PHP install, would I install that as normal and then move the installed dir's into my tarball for the source for the RPM?
I think I'm right but wanted some clarification. I know that the RPM will install the program based off how the configure and make and make install all work just wanted to be sure that was also how it was done for a program that doesn't install that way, like Joomla.
Thanks.
-
scott
- Atomicorp Staff - Site Admin
- Posts: 8355
- Joined: Wed Dec 31, 1969 8:00 pm
- Location: earth
- Contact:
Oh gotcha. No thats not what you do, php packages like this are a special case, but forget about that for a second. A src.rpm is completely self contained, it has everything internal to it to archive, patch, build, and install a piece of software. It also contains macros to run actions before, and after the package is installed, and trigger macros to run before/after its installed when it detects other packages. The action of building an RPM will never involve you installing the package as a requirement to build it.
What makes app vault rpms unique is that you are in effect packaging something for another package management system. That involves more steps, and more changes that have nothing to do with the RPM system. IE, they have their own XML file used to describe the application, and its dependencies. So here are some tips on building a package that is maintainable:
1) dont ever modify the application tarball directly. Use patches instead, even if it takes you an extra hour to do it right. When you update your rpm in a few months, its going to save you a lot of time.
2) leverage the %install macro if you've got to move files around. This is especially handy since the PSA app vault packages rebundle the web app as httpdocs.tar. Dont waste time doing that up front, when you do it in %install it will make your life a lot easier on the next update.
3) Try to avoid using the Epoch: tag (this overrides the version #). I went Epoch crazy early on, and its coming back to haunt me now. Only use the Epoch tag when all other options have been exhausted.
4) When you're building binary RPMs (not app vault), check out mock. It builds a chrooted OS for whatever platform you need to build packages for. This is useful in that it keeps your build tree away from your production OS.
5) Dont make rpms interactive. Avoid any output, special commands, documentation, that get displayed during the installation. If its being run through yum, a web interface, etc. Odds are noone will see it anyway, and worst case, it could break those apps.
What makes app vault rpms unique is that you are in effect packaging something for another package management system. That involves more steps, and more changes that have nothing to do with the RPM system. IE, they have their own XML file used to describe the application, and its dependencies. So here are some tips on building a package that is maintainable:
1) dont ever modify the application tarball directly. Use patches instead, even if it takes you an extra hour to do it right. When you update your rpm in a few months, its going to save you a lot of time.
2) leverage the %install macro if you've got to move files around. This is especially handy since the PSA app vault packages rebundle the web app as httpdocs.tar. Dont waste time doing that up front, when you do it in %install it will make your life a lot easier on the next update.
3) Try to avoid using the Epoch: tag (this overrides the version #). I went Epoch crazy early on, and its coming back to haunt me now. Only use the Epoch tag when all other options have been exhausted.
4) When you're building binary RPMs (not app vault), check out mock. It builds a chrooted OS for whatever platform you need to build packages for. This is useful in that it keeps your build tree away from your production OS.
5) Dont make rpms interactive. Avoid any output, special commands, documentation, that get displayed during the installation. If its being run through yum, a web interface, etc. Odds are noone will see it anyway, and worst case, it could break those apps.