Are you saying that if I grab the source and run rpm --rebuild I can add the additional parameters at this point? Or do you do the preconfigure, then the configure and then the rpm --rebuild to get an installable package?
tm
Larry Gilson wrote:
My first sentence should not have been so sctict but my example did use .src.rpm so I was referring to an RPMS. I have always been able to find the source RPM for whatever I needed. Many times I adjust it to build the final binary and sometimes I don't. Regardless, issuing an 'rpm --rebuild' on the RPMS is building from source and installing the resulting binary RPM is installing from a source that was made on the target machine. No extra work needs to be done just because I like to tailor the install. I still get the benefits of the resulting RPM database which not only helps me but the person who comes in the door after me. Documentation is great but let's face it, something is always missing with documentation.
But then again, we are arguing about tools aren't we. What ever works for you go for it. I just don't buy the line that I want to install from source because it is better. RPMS is just a different format of exactly the same process.
--Larry
-----Original Message-----
From: Terry Milnes [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2003 12:45 PM
Cc: [EMAIL PROTECTED]
Subject: Re: [SAtalk] Spamassassin updates
Hold it a sec, not all rpms contain the source, in fact unless things have changed I thought that most contained precompiled binaries, and that was the problem with them.
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
