I work primarily with source installations, I have no problem tracking what was involved during the install process, granted it means I may have to document some of the process (usually just the order).
eg. webserver, contains many parts, core of which is apache, mysql, php. I want each of these componants installed as independantly as possible, so that in the event of upgrading one (or a componant of one) it has minimum impact on the other.
I choose to install my programs in the paths I prefer with configure options to be what I have determined are best for the given situation.
I keep my compiled src files, if they are acceptable for use on another machine I install them as is, if they need alteration, I use the config file that was created for reference and recompile on the other machine.
I don't have a lot of experience with rpm's besides the usual install of a system, I do realize I could take the time to create an rpm from my source, but choose not to, probably because in a year I may only set up 1/2 dozen new servers, and its rare they have the same architecture.
Now if I were setting up many machines at once I would consider doing the opposite, but in the few cases where I have had to set up two or three servers at the same time, I chose to set up one, and then replicated the entire drive.
Larry Gilson wrote:
RPMs contain the source. RPM is just manages the source and the install. Issuing an 'rpm --rebuild spamassassin-2.60-1.src.rpm' will perform a 'make' and 'make install'. What RPM can bring to the table, however, is a spec file that describes the installation method and all dependencies in a nice database format. In the end, there is more information about the install at an administrator's fingertips. RPMs are the way to go. They don't just work for vanilla installations. They work very well for custom installations. One can package multiple applications including CPAN source dependencies and patches via the RPM. Again, workinging from the RPM source rather than a packaged RPM is usually best as it compiles to fit the environment of the host it is being installed on. If many of the machines are replicated via kickstart, an RPM can be created to be installed during installation or post installation. I really have not even scratched the surface of the flexibility of RPMs. If this was not advantageous, I would not spend the time to find the right source and prepare a spec file for that installation. When I am done the spec file can live through many updates with very little maintenance. Anything else for a Linux system that uses RPM, or similar like yum or apt, is more work. RPM can describe the machine for any administrator that touches the keyboard.
--Larry
-----Original Message-----
From: Darren Coleman [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2003 10:28 AM
To: Chris Santerre; [EMAIL PROTECTED]
Subject: RE: [SAtalk] Spamassassin updates
I'm Linux SysAdmin at the company I work for, I always install everything from source. A colleague, a Windows SysAdmin, installs everything on his Linux boxes from RPMs.
What does that tell you? :)
Although I like the concept behind RPMs, and they work well for vanilla installations (like SA oddly enough), I much prefer compiling things from scratch with whichever machine specific optimisations I care to implement.
Daz
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Santerre
Sent: 16 October 2003 14:48
To: [EMAIL PROTECTED]
Subject: RE: [SAtalk] Spamassassin updates
The topic of updates has come up every new version of SA. You have 3 options:
1) Source 2) RPM 3) CPAN
For some strange reason I always like the source. I think it
goes back to my
childhood, when mom said "Why do you have to do everything the hard way?"
:-)
Anywho, I would love to see this subject broken down on the
wiki in nice
form. I'm not even close to being able to write that. I've only upgraded
once, and that was before it went live. 2.61 will be my
next upgrade.
It's just a suggestion, but any takers? This has been a
great thread.
--Chris
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See
the people
who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php
_______________________________________________
Spamassassin-talk mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
