Hello CentOS, I'm an old hat, and have been compiling my own MySQL, Apache, PHP, OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around with the RPM installs on CentOS, and have basically been able to get most things setup so that they "function" about the same. If I could stick to RPM's rather than compiling my own sources, it would save me a fair bit of time, but of course, it would limit the customization benefit. what I'm wondering, is if anyone on this list has any good reasons why one method would be better, more secure, etc than the other. I'm tempted to start using RPM's instead of compile sources. Comments appreciated, thanks. -- Best regards, Mickael mailto:centos at silverservers.com
On Mon, 2006-01-09 at 00:18 -0800, Mickael Maddison wrote:> Hello CentOS, > > I'm an old hat, and have been compiling my own MySQL, Apache, PHP, > OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around > with the RPM installs on CentOS, and have basically been able to get > most things setup so that they "function" about the same. > > If I could stick to RPM's rather than compiling my own sources, it > would save me a fair bit of time, but of course, it would limit the > customization benefit. what I'm wondering, is if anyone on this list > has any good reasons why one method would be better, more secure, etc > than the other. I'm tempted to start using RPM's instead of compile > sources.Usually in an RPM distro it is better to use RPMS if at all possible. That is because there are several requires that must be met throughout the system that aren't if RPMS are not used. Also, not using RPMS means that you must manually track all security updates to all packages and install them, rebuilding everything as required ... and then there is the issue of backporting to maintain compatibility (which can be very important in the case of specially compile apache modules): http://www.redhat.com/advice/speaks_backport.html So my advise is to use RPMS unless you absolutely have to compile something. Even then, understand the effect that compiling your own items has on the stability of the rest of the system. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060109/a17c47c3/attachment.sig>
On Mon, 2006-01-09 at 00:18 -0800, Mickael Maddison wrote:> Hello CentOS, > > I'm an old hat, and have been compiling my own MySQL, Apache, PHP, > OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around > with the RPM installs on CentOS, and have basically been able to get > most things setup so that they "function" about the same. > > If I could stick to RPM's rather than compiling my own sources, it > would save me a fair bit of time, but of course, it would limit the > customization benefit. what I'm wondering, is if anyone on this list > has any good reasons why one method would be better, more secure, etc > than the other. I'm tempted to start using RPM's instead of compile > sources. > > Comments appreciated, thanks.Well, let's look at why tarballs might be better than packages: - Both are customizable before the build, but packages aren't afterward. No, wait, once a tarball has been compiled then that's it... - Tarballs are easier to manage since they all go in /usr/local. Well, no, they get spread throughout /usr/local. OTOH, packages are managed on a file-by-file basis in the rpmdb. This also makes it easier to discover if files have been modified or corrupted since installation. Okay, I'm out of reasons why tarballs are better. Maybe we should look at the flipside. - Package builds are reproducible. So are tarballs, if you're willing to type in or copy all the commands you used to install them identical to the letter, *plus* can make sure that you have exactly the same set of tarballs built or -devel packages installed before you run configure. Better to just let the spec file handle all that for you ("hey dumbass, you forgot to install openssl-devel!"). - Package builds can run arbitrary commands. So can tarballs, but once again with the typing them in or running a script. With a spec file it's just *all there*. - Package builds are archivable. So are tarballs, at least until you misplace the sheet of paper you wrote the notes on. SRPMs can easily be transmitted via NFS, SMB, optical media, etc., as a single file, and are rebuildable by running "rpmbuild --rebuild" against them. Easy peasy. Well, those are my reasons for using packages over tarballs. I'm sure others have their reasons, but I can only speak for myself. -- Ignacio Vazquez-Abrams <ivazquez at ivazquez.net> http://centos.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060109/28285938/attachment.sig>
Johnny Hughes wrote:> So my advise is to use RPMS unless you absolutely have to compile > something. Even then, understand the effect that compiling your own > items has on the stability of the rest of the system.and when you really really need to compile your own things - build rpms :) -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq
Generally, the only time I would use a tarball and compile myself would be: 1)If no rpm was available 2)If a feature was missing in the rpm version that I needed to enable, ( a classic example here would be milter support in sendmail, but I think thats in the rpms these days). You can reduce still further the chances of no rpms being available by adding the DAG repository to your yum.conf file. This adds a lot of stuff that would otherwise take a bit of finding.... Becareful though, you should be aware of the possible consequences and pitfalls of updating from multiple repositories....generally I use dag to get stuff that isn't available from the standard yum repos... but not for an os update... P. Ignacio Vazquez-Abrams wrote:>On Mon, 2006-01-09 at 00:18 -0800, Mickael Maddison wrote: > > >>Hello CentOS, >> >>I'm an old hat, and have been compiling my own MySQL, Apache, PHP, >>OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around >>with the RPM installs on CentOS, and have basically been able to get >>most things setup so that they "function" about the same. >> >>If I could stick to RPM's rather than compiling my own sources, it >>would save me a fair bit of time, but of course, it would limit the >>customization benefit. what I'm wondering, is if anyone on this list >>has any good reasons why one method would be better, more secure, etc >>than the other. I'm tempted to start using RPM's instead of compile >>sources. >> >>Comments appreciated, thanks. >> >> > >Well, let's look at why tarballs might be better than packages: > >- Both are customizable before the build, but packages aren't afterward. > >No, wait, once a tarball has been compiled then that's it... > >- Tarballs are easier to manage since they all go in /usr/local. > >Well, no, they get spread throughout /usr/local. OTOH, packages are >managed on a file-by-file basis in the rpmdb. This also makes it easier >to discover if files have been modified or corrupted since installation. > >Okay, I'm out of reasons why tarballs are better. Maybe we should look >at the flipside. > >- Package builds are reproducible. > >So are tarballs, if you're willing to type in or copy all the commands >you used to install them identical to the letter, *plus* can make sure >that you have exactly the same set of tarballs built or -devel packages >installed before you run configure. Better to just let the spec file >handle all that for you ("hey dumbass, you forgot to install >openssl-devel!"). > >- Package builds can run arbitrary commands. > >So can tarballs, but once again with the typing them in or running a >script. With a spec file it's just *all there*. > >- Package builds are archivable. > >So are tarballs, at least until you misplace the sheet of paper you >wrote the notes on. SRPMs can easily be transmitted via NFS, SMB, >optical media, etc., as a single file, and are rebuildable by running >"rpmbuild --rebuild" against them. Easy peasy. > >Well, those are my reasons for using packages over tarballs. I'm sure >others have their reasons, but I can only speak for myself. > > > >------------------------------------------------------------------------ > >_______________________________________________ >CentOS mailing list >CentOS at centos.org >http://lists.centos.org/mailman/listinfo/centos > >
I find that the maintainers of the RPMs (at RedHat, and by reference, CentOS) are much more punctual in updating their stuff than I am. So, I prefer to use RPMs whereever possible. To do it all yourself requires constant vigilance and I'm a busy guy... In combination with yum, I'm almost never out of current; a problem I always had in the past. There are still a few things I have to compile and manage with checkinstall, but they are few, now. Viva RPM and yum! -Ben On Monday 09 January 2006 00:18, Mickael Maddison wrote:> Hello CentOS, > > I'm an old hat, and have been compiling my own MySQL, Apache, PHP, > OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around > with the RPM installs on CentOS, and have basically been able to get > most things setup so that they "function" about the same. > > If I could stick to RPM's rather than compiling my own sources, it > would save me a fair bit of time, but of course, it would limit the > customization benefit. what I'm wondering, is if anyone on this list > has any good reasons why one method would be better, more secure, etc > than the other. I'm tempted to start using RPM's instead of compile > sources. > > Comments appreciated, thanks. > > -- > Best regards, > Mickael > mailto:centos at silverservers.com > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >-- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978
Since you all are still talking about compiling RPM's.... I am trying to get the sybase module loaded into php 5.0.4 from the centosplus repository. I cannot seem to get sybase.so to work at all. I got it to work ok by compiling it statically, however I can't seem to get the .so to work. Here's what I get PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/sybase.so' - /usr/lib/php/modules/sybase.so: undefined symbol: dbversion in Unknown on line 0 Here's what I put in the spec file. %package sybase Summary: Connection to Sybase Database Group: Development/Languages Requires: php = %{version}-%{release} sybase-openclient sybase-common BuildRequires: sybase-openclient sybase-common %description sybase The sybase php connection libraries %package sqlite Summary: SQLite shared module Group: Development/Languages Requires: php = %{version}-%{release} sqlite BuildRequires: sqlite-devel %description sqlite SQLite DSO for php %package tidy Summary: Tidy library for php Group: Development/Languages Requires: php = %{version}-%{release} libtidy BuildRequires: libtidy-devel %description tidy Cleans up HTML code Here's the error I get PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/sybase.so' - /usr/lib/php/modules/sybase.so: undefined symbol: dbversion in Unknown on line 0