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