[Cialug] CentOS Yum error

[Zachary Kotlarek]

On Aug 12, 2008, at 4:20 PM, Jeffrey Ollie wrote:

> Hey, you know what?  That's exactly what a .spec file (the input to
> the rpmbuild process) is.  It's a little "recipie" for building
> software from source.


I agree. Both makefiles and RPMs provide a way to store compile-time  
configuration. So would shell scripting. Or a keyboard that supports  
recording and playback -- there are lots of options. My comment was a  
response to the concern about building consistently across systems,  
not an accusation that RPMs had no support for source-based  
distribution.


> I read that as "It's like a packaging system, but you have to do all
> the work yourself."  No thanks, that's what computers are for.


That's how I read your suggestion to build RPMs rather than tarballs.  
I don't want to do the extra work of wedging files into an RPM, or  
convincing the RPM system that the package I built is sufficient to  
meet later dependencies. I'd rather spend a couple of minutes  
developing an actually dependency test -- both tarballs and RPMs  
require some extra bit of work to do dependency tracking, and I prefer  
the runtime-check method over the external database method.


> Checking for features like the way autoconf does is error prone and
> difficult to handle.


It is sometimes done poorly I agree -- autotools is a harsh mistress.  
But RPM dependencies are sometimes poorly configured too, such as  
packages that require the installation of every library that the  
package can link against, rather than just using the perfectly  
sufficient set you already have installed, because the RPM is  
configured to support all available features in a monolithic program.  
Or requiring a specific library version rather than "or  
later" (assuming there's no legitimate reason to require the specific  
version), which I know is frowned upon but is still much too common.

IMHO it's pretty trivial to check for the presence of libraries and  
headers anywhere on the system. With no options you check all the  
standard system paths. You also provide a flag for each prerequisite  
package to override the standard paths just for that package. Almost  
all mature software that has drunk the autotools Kool-Aid supports  
some form of this, which allows for arbitrary locations for all your  
packages. I haven't done a global study of packages, but in the 100+  
packages in my distro I only have to use seds or non-standard  
environmental variables on maybe 5 packages to override hard-coded  
locations, and none of those claim to be autotools friendly.


> Making RPMs is easy, so if you can't find one for your architecture
> it's pretty simple to build it yourself.


Again, so is just building a tarball. Or doing an file system diff to  
build an inventory. Or deciding "I'll never un-install OpenSSL, and if  
I did I'd have to re-compile every major package on the system, so who  
cares where it puts things". I can understand why you want to build  
RPMs when you're using an RPM-based distro, but I'm not using RPMs for  
anything, and it's not clear to me benefit what you think they  
provide, other than the external dependency database, which is one of  
the specific things I don't like about most package managers.


> You must have a different definition of lazy than I do.  I've never
> compiled gnome for myself and I stopped compiling custom kernels long
> ago.  I have better things to do.


I'm pretty sure I said that not having compiling gnome was one of  
things I thought package managers did well. And as I noted, on non-x86  
systems you often have to compile things somewhere at least once no  
matter how painful it main be.


> Sounds like gentoo is the distribution for you...


No. Gentoo has too much package management for me. That's why I roll  
my own.

	Zach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1682 bytes
Desc: not available
Url : http://cialug.org/pipermail/cialug/attachments/20080812/54a939b2/smime.bin