Re: [Pan-users] configure fails on GMIME package check

[Duncan]

Mike Brown posted on Fri, 06 Apr 2012 07:41:41 -0500 as excerpted:

> System is Fedora 13 64-bit.
> 
> When configure is run from the 135 source, it bails when it gets to the
> gmime package test.
> 
> The problem is that while gmime 1.5.1-1 is installed (yum is used), but
> a "pc" file is not created, so pkg-config doesn't think it is on the
> system.
> 
> What is needed to get around this issue?

That one's fairly easy, I think. =:^)

On binary-based distros such as Fedora, most users don't do a lot of 
building from sources, so common library packages are split in half, the 
"runtime" half containing the binaries, etc, and the "dev" half that 
contains the pc files, headers, etc, necessary to build anything 
depending on those libraries.

You have the runtime half installed but are trying to build something 
depending on it, so need the dev half as well.  Look for a gmime-dev 
package of the same version.  Install it and you should get past that, 
but will likely have the same issue with a few other libs as well.

IIRC from my Mandrake years (nearly a decade ago but...), rpm-based 
distros have srpms, aka src.rpms, available, that track build-time 
dependencies and allow you to rebuild the package from sources.  If you 
first find the old pan 0.133 or whatever srpm and try to rebuild pan 
using it, it'll pull in all the dependencies it needed for building that 
version.  That will install most of what you need, tho it's possible 
there will be a few newer or added dependencies in the newer pan version 
that you're actually trying to build.  But it'll be more like one or two, 
than 10 or a dozen, which you'd otherwise be finding out about one at a 
time, as your configure failed at a later point each time as you 
installed them.

FWIW, that's one of the bonuses of running a source-based distro such as 
gentoo, which I run now.  Since the assumption is then that you build 
everything yourself, including whatever triggered your install of the 
library package, it makes little sense to split such packages into 
runtime and -dev packages.  That means that even when building something 
outside the normal packaged system, it's much easier, as far more of them 
are already installed in ordered to build packages that ARE tracked by 
the packaged system. =:^)  Of course the same thing could be accomplished 
with a normally binary-based distro by using srpms for everything, but 
because the assumptions are still different, that's not as easy either -- 
less of it is automated and what is handled automatically doesn't expose 
the same level of build-time options that a good source-based distro will 
give you.  For instance, packages that can be built with additional kde 
and gnome support both, will usually be built with the optional support 
and linked in dependencies turned on for the one the distro defaults to, 
but turned off for the other one, since it'll bring in more 
dependencies.  If you happen to prefer a desktop other than the one the 
distro defaults to, you thus end up with less optional support for it 
than you might like, while it drags in additional deps for the optional 
support for the default desktop, which you normally don't run anyway.  
One of the advantages (beyond not having to worry about -dev packages) of 
a good from-source distro is that such build-time-optional deps will 
normally be exposed for the user to control.  In gentoo, such options are 
exposed as USE flags.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman