Why is net-mail/mailbase being pulled in by Portage?

[saturnalia0]

I was upgrading my world set today and noticed a new install of net-mail/mailbase, which is a bit surprising because I don't have any email software and equery says nothing installed depends on net-mail/mailbase, even indirectly?

Code: Select all

# equery d --indirect net-mail/mailbase
 * These packages depend on net-mail/mailbase:
# grep /var/lib/portage/world -e mail
# eselect news read
No news is good news.
# emerge -ac net-mail/mailbase
--- Couldn't find 'net-mail/mailbase' to depclean.
>>> No packages selected for removal by depclean

I tried following the suggestions from this 2009 thread on how to figure out what is pulling a package in, first with --tree appended to the command I was running to upgrade my world set:

Code: Select all

# emerge --verbose --tree --ask --newuse --changed-use --deep @world

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
Dependency resolution took 8.91 s (backtrack: 0/20).

[ebuild  N     ] net-mail/mailbase-1.8.1::gentoo  USE="pam" 0 KiB
[nomerge       ] x11-drivers/nvidia-drivers-570.124.04:0/570::gentoo  USE="X modules static-libs strip tools -dist-kernel -kernel-open -modules-compress -modules-sign -persistenced -powerd -wayland" ABI_X86="(64) -32" 
[nomerge       ]  x11-libs/gtk+-3.24.48:3::gentoo  USE="X introspection vim-syntax (-aqua) -broadway -cloudproviders -colord -cups -examples -gtk-doc -sysprof -test -wayland -xinerama" ABI_X86="(64) -32 (-x32)" 
[nomerge       ]   gnome-base/librsvg-2.58.5:2::gentoo  USE="introspection vala -debug -gtk-doc" ABI_X86="(64) -32 (-x32)" 
[ebuild  NS    ]    dev-lang/rust-bin-1.83.0-r2:1.83.0::gentoo [1.85.1:1.85.1::gentoo] USE="(-big-endian) -clippy -doc (-prefix) -rust-analyzer -rust-src -rustfmt -verify-sig" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_SLOT="(19)" 0 KiB
[nomerge       ] net-mail/mailbase-1.8.1::gentoo  USE="pam" 
[ebuild  N     ]  acct-user/postmaster-0-r3::gentoo  0 KiB
[ebuild  N     ]  acct-user/mail-0-r3::gentoo  0 KiB
[ebuild  N     ]   acct-group/mail-0-r3::gentoo  0 KiB

But if I'm interpreting that output correctly there is nothing pulling in net-mail/mailbase?

As suggested on that thread I tried equery d -D -a to list everything that depends directly or indirectly on it even if not installed, but after several minutes it did not finish running and the list was so large I don't think it would have been helpful anyway.

My Google-fu didn't show any recent queries about this package either, so, any ideas? This is my world set: https://pastebin.com/raw/dMJ3nXeB

[eeckwrk99]

This is due to this commit.

[saturnalia0]

Thank you. How do I remove it? I don't need it.

Code: Select all

# emerge --deselect net-mail/mailbase
>>> No matching atoms found in "world" favorites file...

Tried to mask it, but then world set upgrade fails because it is required but masked.

[eeckwrk99]

Code: Select all

# emerge --deselect net-mail/mailbase
>>> No matching atoms found in "world" favorites file...

This is expected, net-mail/mailbase is now part of the @system set, not the @world set. Therefore, `--deselect` won't do anything in this case:

--deselect [ y | n ], -W
Remove atoms and/or sets from the world file. This action is implied by uninstall actions, including --depclean, --prune and --unmerge. Use --deselect=n in order to prevent uninstall actions from removing atoms from the world file.

How do I remove it? I don't need it.

I don't know, I never tried to remove a package from the @system set.

It's probably not a good idea though. I guess Portage prints a nice warning for good reasons:

Code: Select all

emerge -C net-mail/mailbase
!!! 'net-mail/mailbase' is part of your system profile.
!!! Unmerging it may be damaging to your system.

net-mail/mailbase: 1.8.1 none none

All selected packages: =net-mail/mailbase-1.8.1
Would you like to unmerge these packages? [Yes/No]

Maybe there's a way to actually do it. As far as I'm concerned I'll just keep it.

[sam_]

emerge -C won't stop it being pulled back in, anyway. You can modify the system set via /etc/portage/profile/packages, but unless the package is really causing a problem (if so, what problem? file a bug?), I'd keep it, as it's expected to have mail work properly.

[logrusx]

The Gentoo Handbook has historically provided instructions to create new
users with the `-m` flag. However, this now results in the error
"Creating mailbox file: No such file or directory" because
`/var/spool/mail` is no longer included in stage3 tarballs.

TBH I don't find that a reasonable justification to include something not everybody needs. I've never ever used mail on Gentoo. Not that I remember of. I also remember setting up mail once, maybe in 2000 or something like that. I haven't found the usefulness of it for me.

I also didn't find a way to modify the system set using /etc/portage/profile/packages. Neither *, nor missing star, nor - on the package line helps.

EDIT: found it:

Code: Select all

-*net-mail/mailbase

Best Regards,
Georgi

[sam_]

The Gentoo Handbook has historically provided instructions to create new
users with the `-m` flag. However, this now results in the error
"Creating mailbox file: No such file or directory" because
`/var/spool/mail` is no longer included in stage3 tarballs.

TBH I don't find that a reasonable justification to include something not everybody needs. I've never ever used mail on Gentoo. Not that I remember of. I also remember setting up mail once, maybe in 2000 or something like that. I haven't found the usefulness of it for me.

I also didn't find a way to modify the system set using /etc/portage/profile/packages. Neither *, nor missing star, nor - on the package line helps.

EDIT: found it:

Code: Select all

-*net-mail/mailbase

Best Regards,
Georgi

Do you actually find it unreasonable, given it consumes essentially no disk space, costs no time to install, and nobody will notice it other than it being pulled in newly now (if it had been there all along, nobody would care), or do you just disagree with it? I don't think it's helpful to say unreasonable for a case like this.

Note that your quote also omits some of the rationale (and linked bugs) in the ML thread (though I think the version which got committed didn't have this detail wrt the rationale, it did have the bugs).

We've had a number of complaints and confused users thinking something is broken because of useradd -m warning on this, and tools may expect mail and cron mails to work correctly.

[logrusx]

Do you actually find it unreasonable, given it consumes essentially no disk space, costs no time to install, and nobody will notice it other than it being pulled in newly now (if it had been there all along, nobody would care), or do you just disagree with it? I don't think it's helpful to say unreasonable for a case like this.

I find it inconvenient to have to read documentation to find out what the implications of having something I don't need are. The justification doesn't convince me.

We've had a number of complaints and confused users thinking something is broken because of useradd -m warning on this, and tools may expect mail and cron mails to work correctly.

Exactly this part I find unreasonable. Fixing an example in the Handbook by adding a package instead of fixing the example to not require that package. However I wasn't sure about that and that's why I wrote it here, instead of in the bug. I hoped for a discussion of some kind, instead of blindly commenting in or filing bugs.

Regarding the tools that may expect mail and cron, shouldn't that be arranged in the ebuilds? Like einfo or ewarn? Plenty of ebuilds do that. Also when someone installs such tools it implies they know what they are doing. Cron is another tool I haven't used at least since 2010 (when I took a break from Linux and deleted my installation) and I don't miss it. I think [on my system] it was only used to rotate logs back then.

Best Regards,
Georgi

[sam_]

I don't find the use of the term unreasonable appropriate here, so I'm bowing out.

[logrusx]

I don't find the use of the term unreasonable appropriate here, so I'm bowing out.

Sorry, English is not my first language. Maybe there's a better word, but my vocabulary is only so large and I already struggle to find even those words.

Unreasonable => doesn't give me a reason, doesn't not convince me. Maybe I should have used convincing instead?

Neither did the bugs provide any reasoning beyond what I quoted. I looked at all three of them.

Anyways, I already short circuited that package and prefer to keep it that way. Unless something starts requiring, which is unlikely, given that I haven't needed it for 7 years now.

Best Regards,
Georgi

[shimbob]

EDIT: found it:

Code: Select all

-*net-mail/mailbase

Thank you for this. I have neither cron or even a syslog so keeping out other unneeded stuff makes me happy.

[pietinger]

I find it inconvenient to have to read documentation to find out what the implications of having something I don't need are. [...]

You are an advanced Gentoo user - but there are also many users who have only come to Gentoo very fresh. For whom it is easier to clarify the following two questions:

* What do I have to activate so that X works?
* What do I have to deactivate because I don't need Y?

Yes, I have already written here that Gentoo was not so user-friendly in the past: viewtopic-p-8861173.html#8861173

In addition, it is assured that our Gentoo developers always try to solve problems as intelligently as possible, which also affects the question of the effort-benefit ratio. What requires more effort: to install a harmless small package in addition, or to adapt many (hundreds?) ebuilds? (If that is sufficient at all; I don't know how an ebuild should check whether users were created with -m).

I am also a fan of a minimal system, but I'm really not interested in such little things ... and yes, you always have to read documentaries at Gentoo; even a newbie has to read our AMD64 handbook ... but Gentoo would not be so user-friendly once a newbie has to read through our complete wiki ... I would rather impose it on an advanced user.

[logrusx]

After I was surprised not to find any documentation, I opened the ebuild and was even more surprised not to see a SRC_URI. I checked the inherit clause to see if there's a specific eclass that might be defining that and then stared at arc_install and noticed a few ${FILESDIR} references which made me realize all the contents of this package are in tree in the files directory. I realized those are the missing files referenced in the quote above that are no longer included in the stage3 tarball and this is not a real package, at least not a real MTA but some compatibility files.

So, no, you don't need to modify system set. It's more likely this restores a previous state without being in the stage 3 tarball.

And no, this change is not unreasonable, however the commit message is not clear.

It turns out not my wording, but the wording of the commit message is not good. This whole thing made an impression a new package was being added while in fact those are just a few files, what's more they are plain text files:

Code: Select all

>>> Merging net-mail/mailbase-1.8.1 to /
--- /var/
>>> /var/mail -> spool/mail
--- /usr/
--- /usr/share/
--- /usr/share/man/
--- /usr/share/man/man5/
>>> /usr/share/man/man5/mailcap.5.bz2
--- /etc/
>>> /etc/mail/
>>> /etc/mail/aliases
>>> /etc/mailcap
--- /etc/pam.d/
>>> /etc/pam.d/pop
>>> /etc/pam.d/pop3 -> pop
>>> /etc/pam.d/imap
>>> /etc/pam.d/imaps -> imap
>>> /etc/pam.d/pops -> pop
>>> /etc/pam.d/pop3s -> pop
>>> /etc/pam.d/imap4s -> imap
>>> /etc/pam.d/imap4 -> imap
>>> net-mail/mailbase-1.8.1 merged.

I apologize if my perception of "unreasonable" sounded disrespectful. As I already said, English is not my first language and it's not easy to be careful with your language and say what you think in the same time in a language you're not fluent with. As I said earlier, I didn't comment in the bug of filed another one just because I was not confident what I thought was correct and that's why I wrote it here, which in the end led to clarification, which was my goal.

Why I didn't check that earlier? I expected there would be a ton of man pages at least. After all it sounded like this is an MTA.

Best Regards,
Georgi

[grant123]

For what it's worth I prefer Gentoo's not-installed-unless-you-need-it distro management approach.

[logrusx]

For what it's worth I prefer Gentoo's not-installed-unless-you-need-it distro management approach.

Well it's kind of needed. For compatibility reasons. I too remember hitting that error but I was not intimidated by it as I knew it was not relevant. But a new user would definitely be at least confused. And now that I understand the reasoning behind it, it's quite intelligent and simple solution which doesn't hurt anyone. In fact my problem with it was I wasn't understanding what's going on. As I already reported above - nothing much.

Of course you're free to modify the system set but it's not necessary. And generally you should not need that.

Best Regards,
Georgi