On Sat, Jul 21, 2018 at 18:10:58 -0400, Mike Gilbert wrote:
> On Sat, Jul 21, 2018 at 5:03 PM, Alan Mackenzie <a...@muc.de> wrote:
> > Hello, Gentoo.
> > Right at the moment, I feel a lot of sympathy with Alan Grimes, and need
> > a lot of restraint in avoiding the use of swear words in describing some
> > Gentoo developer.
> > ...
> > nullmailer installs a file /usr/sbin/sendmail. This masks out the
> > correct /usr/bin/sendmail (which is a symbolic link to s/qmail, which I
> > installed by hand, not using emerge) because /usr/sbin is before
> > /usr/bin in $PATH.
> > ...
> > But what's the proper method to tell my gentoo system that I don't want
> > crud like nullmailer installed? How can I guard myself against such
> > presumptiousness on the part of the Gentoo devs in the future?
Apologies to the maintainers and users of nullmailer. I didn't mean to
say what I said about it, and I'm sure it's a perfectly good package.
> You must have installed a package that depends on virtual/mta,
> presumably because it needs to send emails.
The package was gnupg, which surely doesn't need to send email.
> Had you installed qmail using portage, the virtual/mta dep would have
> been satisfied by it, and nullmailer would not have been installed in
> the first place. However, you didn't do that, and so portage had no
> idea qmail was installed.
qmail suffered long from a "non-standard" copyright, where modified
versions could not be circulated. Instead, the original sources
together with (lots of) patches did the rounds. About a decade ago, the
author of Qmail, Daniel Berstein, put it into the public domain. Two or
three people, independently, have gathered the fragments into coherent
packages and done things like ading IPv6, one of them being Erwin
Hoffmann's s/qmail, which I use. None of these packages have Gentoo
ebuilds.
> A possible workaround would be to add mail-mta/netqmail to
> package.provided on your system. However, there's still no guarantee
> that your custom-built qmail software will work with other packages
> provided by Gentoo.
Thanks, I didn't know about package.provided. It's not quite ideal, but
suffices as a workaround. What's suboptimal about it is that you can
only specify particular versions of packages, not the package as such.
So, if I put
virtual/mta-1
into my package.provided, I'm going to suffer again in the same way when
somebody releases virtual/mta-2. As a workaround, my p.p. looks like
this:
virtual/mta-0
virtual/mta-1
virtual/mta-1.1
virtual/mta-1.2
virtual/mta-2
virtual/mta-2.1
virtual/mta-2.2
virtual/mta-3
virtual/mta-3.1
virtual/mta-3.2
virtual/mta-4
virtual/mta-4.1
virtual/mta-4.2
virtual/mta-5
virtual/mta-5.1
virtual/mta-5.2
virtual/mta-6
virtual/mta-6.1
virtual/mta-6.2
, which should protect me for quite a few years.
> Regarding your accusations: Gentoo developers cannot anticipate every
> possible thing you might do on your system, especially when you start
> installing custom programs in paths that are traditionally managed by
> our package manager. Using portage you can customize your system
> extensively, without needing to custom build your own software.
Life is not so simple, but I take the point. s/qmail had no option to
build into /usr/local, and I didn't perceive any particular need to try
to move it by hand.
> If that's not good enough for you, go build a Linux from Scratch
> system and enjoy the lack of any package management or support
> whatsoever.
That's the other extreme.
Thanks for the reply.
--
Alan Mackenzie (Nuremberg, Germany).
