vsftpd-1.2.2 currently depends on sys-apps/xinetd, but it can perfectly run as a standalone daemon. What about an USE flag? Reproducible: Always Steps to Reproduce: You can currently use --nodeps to bypass this dependency, but that's evil.
*** Bug 66224 has been marked as a duplicate of this bug. ***
There currently is no USE flag for xinetd, and this affects other apps as well. Until/if one is created, xinetd will have to be emerged. The default config is setup to use xinetd anyway, so if an end user chooses not to use it, then they can unemerge is afterwords. Though it would be nice to have the option in the future.
I note that a local "xinetd" USE flag does exist for the qpopper package (try "euse -i xinetd"). Couldn't a local xinetd USE flag be added to the ebuild for vsftpd too? (at least until the creation of a global USE flag -- assuming it's desired) The only problem I see with this is that it changes the "default" action for the ebuild. That is, unless someone updates package.use to include xinetd in the USE flags for vsftpd, emerging it will do so in standalone mode -- the opposite of what happens at the moment. Might cause confusion? An alternative might be to add a local USE flag called "standalone" to the vsftpd ebuild instead. That would keep the "default" action of the ebuild the same, though that would cause problems / confusion if a global xinetd USE flag were created in the future.
I think using 'xinetd' as the name of the USE flag would be misleading, because the package would work with both, inetd and xinetd. In fact, the inetd USE flag is also already in use. $ grep -n inetd /usr/portage/profiles/use.local.desc 111:dev-db/firebird:inetd - If you want inetd version instead of a superserver (daemon) 582:net-mail/qpopper:xinetd - If you want inetd version instead of standalone
Fixed in vsftpd-2.0.3