On 06/09/2013 18:45, Jarry wrote: > On 06-Sep-13 18:29, Canek Peláez Valdés wrote: >> On Fri, Sep 6, 2013 at 11:22 AM, Jarry <mr.ja...@gmail.com> wrote: >>> On 06-Sep-13 18:14, Canek Peláez Valdés wrote: >>>> >>>> On Fri, Sep 6, 2013 at 10:51 AM, Jarry <mr.ja...@gmail.com> wrote: >>>>> >>>>> On 06-Sep-13 17:32, Michael Orlitzky wrote: >>>>>> >>>>>> >>>>>> On 09/06/2013 11:23 AM, Jarry wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It wasn't part of @system before, you just removed the thing that >>>>>>>> pulled >>>>>>>> it in. >>>>>>> >>>>>>> >>>>>>> >>>>>>> No I did not. mail-mta/ssmtp was part of stage3. And I did not >>>>>>> remove now any "thing" that pulled it in. All I did was >>>>>>> "emerge --ask --update --deep --newuse world". >>>>>>> >>>>>>> As a result, python-exec, python-argparse and libxml2 were >>>>>>> reinstalled and automake-wrapper, gtk-doc-am, eselect and >>>>>>> linux-header updated. Nothing else. >>>>>>> >>>>>>> After that I did "emerge --depclean" and the above mentioned >>>>>>> packages were suddenly removed... >>>>>>> >>>>>> >>>>>> It could be that a package's deps were updated to no longer include >>>>>> virtual/mta. But it was never part of @system, you can check for >>>>>> yourself: >>>>>> >>>>>> >>>>>> >>>>>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/base/packages?view=log >>>>>> >>>>> >>>>> >>>>> >>>>> Then something got broken because I have packages installed >>>>> that need mailer (i.e. app-admin/monit or sys-fs/mdadm are >>>>> configured to send emails). And these packages do not have >>>>> "mail" use-flag, because their maintainers apparently expect >>>>> standard *nix mailer (/usr/bin/sendmail) exists on the system... >>>>> >>>>> So now I have "stable" system, updated to the latest level, >>>>> where a lot of things suddenly do not work. This should *never* >>>>> happen! If it was some package's dep that caused it, it's clear >>>>> this change was premature... >>>> >>>> >>>> I think is a bug in the packages. In my system the only package that >>>> pulls vitual/mta (and therefore ssmtp) is vixie-cron. >>> >>> >>> That is strange. I have sys-process/vixie-cron-4.1-r12 and yet >>> revdep-rebuild does not want to pull virtual/mta. But It should, >>> as cron can be configured to send emails too. >> >> Read my last mail; they changed the RDEPEND for the cron eclass. >> >>> As I wrote: there are *many* packages that expect standard >>> *nix mailer exists! If it does not, a lot of packages must >>> be fixed to include mailer as dependency. >> >> The devs disagree. I think I'm with them; the packages in question >> actually work, it just happens that they can't send mails anymore. If >> you need/want them to send mails, install an MTA. >> > > "Just" can't send mails. So if mdadm detects failed drive in raid1 > and I do not get mail about it, I will discover it at least when > the 2nd drive fails. That's a relief... > > Why is there no global use-variable "mta"? Why not even local > for packages that might use mailer? This goes completely against > Gentoo-principles, if user has to search which other packages are > required and install them manually. Is it not what we have > use-flags for?
Relax Jarry, take a chill-pill. It's Friday and weekend is almost here. Let me point out the mistakes you have made. You ran emerge --depclean blindly and let it do $WHATEVER. Or, you didn't read the output and notice it was about to nuke the mta. You assume and hope that you will always have a mailer. You didn't check if it really was in @system, or in the profile, or set by a USE flag. The mta just happened to be there, and you just assumed. Turns out it's there because the cron eclass just happened to think it was a good idea. It changed it's mind. cron is not part of @system either. You had to emerge it yourself, and that just happened to bring along an mta. If you wanted sendmail or postfix instead of ssmtp, you would have had to do that manually too. Just emerge the mta of your choice and put it in world. Then ask for the docs to be updated. Or, seeing as it's now a wiki, edit the docs yourself. -- Alan McKinnon alan.mckin...@gmail.com
