On Tuesday 29 May 2007, Daevid Vincent wrote:
> I haven't done an emerge on my server in quite a while, but now that
> I've upgraded the CPU/RAM, I figure it's about time.
>
> There are a few packages I'm a bit apprehensive about upgrading.
> "exim" being one. I hate that MTA. It was a nightmare to setup and
> get working properly, and now I don't want to break it. (a friend set
> it up actually, as that was the MTA he used.)
>
> daevid portage # esearch exim
> * mail-mta/exim
> Latest version available: 4.67
> Latest version installed: 4.54
> Size of downloaded files: [no/bad digest]
> Homepage: http://www.exim.org/
>
> So I have this in my package.mask:
> >=mail-mta/exim-4.55
That's correct. If you are happy with exim-4.55 and there's no reaosn
you can find to upgrade it, just stick with what you have
> (Is this upgrade from 4.54 to 4.67 very smooth? Should I worry? I
> dread having to deal with exim.conf again, and the exim users list is
> very elitist. Usually saying RTFM for most issues -- but they all are
> experts or mail admins. I'm not. Nor do I want to be.)
>
> But when I do an "emerge -aut world", I get this blocking issue:
A better command is probably 'emerge -avuNDt world'. This will pick up
changes in USE flags (N) and also update any dependencies that are not
in world (D)
> These are the packages that would be merged, in reverse order:
> ...snip...
> [nomerge ] x11-misc/xscreensaver-5.02 [5.01-r2]
> [nomerge ] x11-apps/appres-1.0.1 [1.0.0]
> [ebuild U ] x11-libs/libX11-1.1.1-r1 [1.0.3-r1] USE="-xcb%"
> [nomerge ] sys-process/vixie-cron-4.1-r10 [4.1-r9]
> [ebuild N ] mail-mta/ssmtp-2.61-r2 USE="ipv6 ssl -mailwrapper
> -md5sum"
> [nomerge ] kde-base/kdegraphics-3.5.5-r2 [3.5.5]
> [nomerge ] media-libs/lcms-1.15 [1.14-r1] USE="-tiff*"
> [nomerge ] dev-lang/swig-1.3.31 [1.3.25] USE="ruby* -lua%
> -mono% -ocaml% -pike%"
> [nomerge ] dev-lang/php-5.2.2-r1 [5.2.1-r3]
> [nomerge ] net-misc/curl-7.15.1-r1 [7.15.1] USE="ldap*
> -idn*" [ebuild U ] net-nds/openldap-2.3.30-r2 [2.3.27]
> USE="-smbkrb5passwd%"
> [nomerge ] media-gfx/imagemagick-6.3.3 [6.2.9.5]
> [ebuild U ] x11-libs/libXt-1.0.5 [1.0.4]
> ...snip...
> [blocks B ] mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2)
>
> (also, I never understand the --tree option. Does this mean that
> "vixie-cron" is the issue, or "kdegraphics" is the issue? Being
> reverse order, I am guessing vixie-cron, yet it says "nomerge" so
> that seems like, why would it care, plus it's worked fine all these
> years with the exim I have installed. Conversely, why would
> kdegraphics give a hoot about a mail transport? I don't get it.)
It means that vixie-cron depends on ssmtp (i.e. vixie-cron uses ssmtp
for some reason). Obviously, ssmtp will be merged first so that it is
there when vixie-cron is merged. The output does indeed show that
packages will be emerged in bottom-up order, but the list of
dependencies is top-down.
The vixie-cron ebuild inherits the cron eclass, and that file has this:
RDEPEND="!virtual/cron
virtual/mta
>=sys-process/cronbase-0.3.2"
So it wants a virtual mta, and somehow believes that exim doesn't
provide it, so portage has (helpfully...) suggested ssmtp. vixie-cron
doesn't need to be recompiled, as it's an RDEPEND and only needed at
run time (hence the nomerge)
I would suggest you investigate why portage thinks exim does not provice
virtual/mta capabilities
> And maybe I'm using this tool wrong, but this just adds to my
> confusion.
>
> daevid portage # equery depends mail-mta/ssmtp
> [ Searching for packages depending on mail-mta/ssmtp... ]
>
> daevid portage # equery depends mail-mta/exim
> [ Searching for packages depending on mail-mta/exim... ]
> app-admin/sudo-1.6.8_p9-r2 (virtual/mta)
> app-admin/tripwire-2.3.1.2-r2 (virtual/mta)
> dev-lang/php-5.2.1-r3 (virtual/mta)
> mail-client/mailx-8.1.2.20040524-r1 (virtual/mta)
> mail-filter/procmail-3.22-r7 (virtual/mta)
> net-mail/mailman-2.1.5-r4 (virtual/mta)
> sys-power/apcupsd-3.10.18-r1 (virtual/mta)
> sys-process/vixie-cron-4.1-r9 (virtual/mta)
What's confusing about that? equery found 8 packages that claim to
depends (or use) ssmtp. That's perfectly normal. It's the packages that
depend on ssmtp, not the packages you have installed and are
configured/USE-flagged to use it
alan
--
Optimists say the glass is half full,
Pessimists say the glass is half empty,
Developers say wtf is the glass twice as big as it needs to be?
Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five
--
[EMAIL PROTECTED] mailing list
