[gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Daevid Vincent]

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        

(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:

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.)

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)

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Alan McKinnon]

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
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

On Tuesday 29 May 2007 10:32:23 Daevid Vincent wrote:
> *  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
[SNIP]
> [nomerge      ] sys-process/vixie-cron-4.1-r10 [4.1-r9]
> [ebuild  N    ]  mail-mta/ssmtp-2.61-r2  USE="ipv6 ssl -mailwrapper
[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.

vixie-cron has a run-time dependency on virtual/mta which can be satisfied by 
both exim and ssmtp (and 8 other packages in the tree). ssmtp is the default 
provider.

What has happened is that all versions of exim in the tree that you haven't 
masked have been removed from the tree. I.e. there are no versions in the 
tree below 4.55. Therefore it suggests installing the default provider of 
virtual/mta which is blocked by the version of exim which is still installed 
although not installable (not in the tree). It matters despite the "nomerge" 
because it's a run-time dependency rather than build-time.

You have at least four options. The first option is to upgrade exim and hope 
it'll work. I have no knowledge about exim so I cannot tell you whether it 
will. The second is to restore the ebuild for your installed version in an 
overlay (you can pull it from /var/db/pkg/mail-mta/exim-4.54/) thereby 
restoring a non-masked version of exim.. The third is to add mail-mta/exim to 
package.provided (see `man portage`). The fourth is to unmerge exim and use 
another mta (I'm using postfix).

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

On Tuesday 29 May 2007 06:51:12 Bo Ørsted Andresen wrote:
> On Tuesday 29 May 2007 10:32:23 Daevid Vincent wrote:
> > *  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
>
> [SNIP]
>
> > [nomerge      ] sys-process/vixie-cron-4.1-r10 [4.1-r9]
> > [ebuild  N    ]  mail-mta/ssmtp-2.61-r2  USE="ipv6 ssl -mailwrapper
>
> vixie-cron has a run-time dependency on virtual/mta which can be satisfied
> by both exim and ssmtp (and 8 other packages in the tree). ssmtp is the
> default provider.  It matters despite
> the "nomerge" because it's a run-time dependency rather than build-time.
>
> You have at least four options.

Another, less tenable, option is to use paludis as your package manager.  It 
will satisfy dependencies (including virtuals) with installed packages.  
Also, paludis's --show-reasons summary option is usually easier to understand 
and more informative than emerge/portage's --tree option.

However, paludis does have some missing features that may be critical for your 
environment: binary packages (both building and using) and a revdep-rebuild 
equivalent (although this can be hacked around) AND you can't "simply" switch 
between using paludis and emerge/portage; they use the same VDB, but 
repositories are configured differently and paludis can perform some caching 
that emerge/portage will not use/update.  It also runs the ebuild test phase 
by default which results in more merge failures and thus more required 
interaction; you can turn that off if you desire.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

On Wednesday 30 May 2007 05:39:01 Boyd Stephen Smith Jr. wrote:
> However, paludis does have some missing features that may be critical for
> your environment: binary packages (both building and using)

True. And it misses pkgmoves and slotmoves (profiles/updates/*).

> and a revdep-rebuild equivalent (although this can be hacked around)

With the ruby use flag there's check_linkage.rb.

> AND you can't "simply" switch between using paludis and emerge/portage; they
> use the same VDB, but repositories are configured differently

So if you want to use both at the same time you can either keep their configs 
synchronized manually or use the portage use flag for paludis and run it 
with '-E portage' (the latter loses features though).

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

On Wednesday 30 May 2007 07:20:45 Bo Ørsted Andresen wrote:
> On Wednesday 30 May 2007 05:39:01 Boyd Stephen Smith Jr. wrote:
> > However, paludis does have some missing features that may be critical for
> > your environment:
> > a revdep-rebuild equivalent (although this can be hacked around)
>
> With the ruby use flag there's check_linkage.rb.

I didn't know about that.  I've been using revdep-rebuild, but having it 
pass "cat-egory/package" as an additional argument to emerge, which cause the 
emerge to fail.  I then run paludis using packages from one of 
revdep-rebuild's temporary files.  Finally I remove revdep-rebuild's 
temporary files.  It's a nasty hack, but it has worked so far.

I found check_linkage.rb, but it's not installed (or linked) to any of the 
standard $PATH directories.  Instead, it's in a "demo" directory.  Is it 
fully functional?

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Thursday 31 May 2007 04:09:10 Boyd Stephen Smith Jr. wrote:
> I found check_linkage.rb, but it's not installed (or linked) to any of the
> standard $PATH directories.  Instead, it's in a "demo" directory.  Is it
> fully functional?

Yes. You run it with ruby. It does still lack a couple of features though.  
Namely --library and the ability to pick another version when the ebuild for 
an installed version has been removed. At least the latter is soon to come. 

But at least it will never use the horrible hack that revdep-rebuild uses 
with --package-names because of the lack of support for the 
=category/package-version:slot syntax in portage-2.0* which it still 
supports.. :)

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

On Wednesday 30 May 2007 21:20:52 Bo Ørsted Andresen wrote:
> On Thursday 31 May 2007 04:09:10 Boyd Stephen Smith Jr. wrote:
> > I found check_linkage.rb, but it's not installed (or linked) to any of
> > the standard $PATH directories.  Instead, it's in a "demo" directory.  Is
> > it fully functional?
>
> Yes. You run it with ruby.

Yeah, I figured a .rb was run with ruby. :P

If it's really useful, it should be chmod'd +x and installed or linked 
into /usr/sbin.  I can do that myself (in that case /usr/local/sbin), but 
such wonderful utilities shouldn't be hidden. :)

> It does still lack a couple of features though. 
> Namely --library and the ability to pick another version when the ebuild
> for an installed version has been removed. At least the latter is soon to
> come.

I noticed it was also trying to reinstall all my binary-only packages: 
sun-jdk, blackdown-jdk, skype, and emul-linux-x86-compat.  I guess 
revdep-rebuild has some blacklist that prevents it from doing so.

> But at least it will never use the horrible hack that revdep-rebuild uses
> with --package-names because of the lack of support for the
> =category/package-version:slot syntax in portage-2.0* which it still
> supports.. :)

You mean that portage actually supports slot deps now?

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Paul Varner]

On Thu, 2007-05-31 at 04:20 +0200, Bo Ørsted Andresen wrote:
> But at least it will never use the horrible hack that revdep-rebuild uses 
> with --package-names because of the lack of support for the 
> =category/package-version:slot syntax in portage-2.0* which it still 
> supports.. :)

Hey, I'm proud of that horrible hack!

However, on that note, I can't wait to get rid of it and use the
=category/package-version:slot syntax. I've been strongly thinking of
doing it in 0.2.4 which is in the pre-release cycle right now.

Regards,
Paul
--
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

On Thursday 31 May 2007 04:37:52 Boyd Stephen Smith Jr. wrote:
> If it's really useful, it should be chmod'd +x and installed or linked
> into /usr/sbin.  I can do that myself (in that case /usr/local/sbin), but
> such wonderful utilities shouldn't be hidden. :)

I can't really disagree with that, heh. It has been added to the faq though, 
however, it won't go online till the next release.

> > It does still lack a couple of features though.
> > Namely --library and the ability to pick another version when the ebuild
> > for an installed version has been removed. At least the latter is soon to
> > come.
>
> I noticed it was also trying to reinstall all my binary-only packages:
> sun-jdk, blackdown-jdk, skype, and emul-linux-x86-compat.  I guess
> revdep-rebuild has some blacklist that prevents it from doing so.

Ah yeah, forgot that one. It doesn't parse the variables that control where 
revdep-rebuild should and shouldn't look and what libs it should ignore. 
Instead it iterates over each installed package and runs ldd on every *.la 
and *.so* file.

> > But at least it will never use the horrible hack that revdep-rebuild uses
> > with --package-names because of the lack of support for the
> > =category/package-version:slot syntax in portage-2.0* which it still
> > supports.. :)
>
> You mean that portage actually supports slot deps now?

Yes. There shouldn't have been an equal sign though. Using it in the tree is 
against policy, however, until we get an EAPI bump. But the new 
python-updater does take advantage of it and drops the horrible hacks it used 
to use. Also because portage has become much better at figuring out the build 
order with --deep when handed a list of broken packages in random order. 

Really dropping the horrible hacks in revdep-rebuild would be easy when just 
raising the dependency on portage to >=2.1.2.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Thursday 31 May 2007 04:57:53 Paul Varner wrote:
> > But at least it will never use the horrible hack that revdep-rebuild uses
> > with --package-names because of the lack of support for the
> > =category/package-version:slot syntax in portage-2.0* which it still
> > supports.. :)
>
> Hey, I'm proud of that horrible hack!

Didn't say you shouldn't be. It was necessary when you made it.

> However, on that note, I can't wait to get rid of it and use the
> =category/package-version:slot syntax. I've been strongly thinking of
> doing it in 0.2.4 which is in the pre-release cycle right now.

The equal sign was a mistake. I've actually been meaning to poke you about 
that. At the same time you should drop the --emptytree parsing and just 
use --deep directly. With the circular deps in the tree now that gets much 
better results.

:)

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] FW: mail-mta/exim (is blocking mail-mta/ssmtp-2.61-r2) (more info added)

[Paul Varner]

On Thu, 2007-05-31 at 05:09 +0200, Bo Ørsted Andresen wrote:
> The equal sign was a mistake. I've actually been meaning to poke you about 
> that. At the same time you should drop the --emptytree parsing and just 
> use --deep directly. With the circular deps in the tree now that gets much 
> better results.

The use of --emptytree has already been removed in the the 0.2.4
versions of gentoolkit.

2007-03-07 Paul Varner <fuzzyray@gentoo.org>
        * revdep-rebuild: Change ordering algorithm to use --deep instead of
        --emptytree on the advice of zmedico

So that one is already completed.

Regards,
Paul
--
gentoo-user@gentoo.org mailing list