/etc/xinetd.d/tftp has server_args = /var/lib/tftpboot Why not create this folder (with test for existing) if the package is emerged? I did not look into the other services.
I see that it also defaults to running as 'nobody', which is probably a bad idea. It would probably be worthwhile to create a dedicated user for tftp daemons (acct-user/tftp).
guessing you didn't mean iputils since that doesn't provide tftp packages must not create /var paths in the ebuild itself. we can have its init.d script use checkpath, and install a tmpfiles.d for the xinetd usage. a dedicated user is fine, but it's not a super big deal since it's a read-only service.
(In reply to SpanKY from comment #2) > guessing you didn't mean iputils since that doesn't provide tftp The iputils ebuild has USE flags for tftp and tftpd. I have no idea where you got this idea from.
(In reply to SpanKY from comment #2) > packages must not create /var paths in the ebuild itself. It is fairly common for ebuilds to keepdir paths below /var/lib.
(In reply to SpanKY from comment #2) > a dedicated user is fine, but it's not a super big deal since it's a > read-only service. Looking through tftpd.c in the iputils source, it does appear to support receiving files from the client.
(In reply to SpanKY from comment #2) > guessing you didn't mean iputils since that doesn't provide tftp > > a dedicated user is fine, but it's not a super big deal since it's a > read-only service. You can push files to the server. so rw.
(In reply to Mike Gilbert from comment #4) > (In reply to SpanKY from comment #2) > > packages must not create /var paths in the ebuild itself. > > It is fairly common for ebuilds to keepdir paths below /var/lib. those ebuilds are all broken and violating QA. existing broken code is not justification for adding more.
(In reply to SpanKY from comment #7) > those ebuilds are all broken and violating QA. existing broken code is not > justification for adding more. There is no Gentoo policy that says "do not install things in /var/lib".
It looks like tftpd is likely to be removed upstream. https://github.com/iputils/iputils/issues/363
If you want to see a change in that policy(In reply to SpanKY from comment #7) > those ebuilds are all broken and violating QA. existing broken code is not > justification for adding more. I can imagine for some use cases that it might be useful to treat /var as a completely volatile data store that can be wiped out at any time. However, current Gentoo ebuild policy/practice does not require supporting this. Arguing about this on a random bug report will not be very productive. If this is something you want to pursue, here are some suggested next steps: 1. Propose a policy on the gentoo-dev mailing list, and listen to the feedback/suggestions. 2. Update the Gentoo policy guide. https://projects.gentoo.org/qa/policy-guide/index.html 3. Update the related install QA check. https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/install-qa-check.d/08gentoo-paths 4. Update the existing ebuilds that install directories under /var.
(1) portage has been warning about it for years: https://gitweb.gentoo.org/proj/portage.git/tree/bin/install-qa-check.d/20runtime-directories (2) this is the entire point of checkpath & tmpfiles.d. (3) having /var/lib or similar paths wiped or broken should not require an unmerge & re-emerge of a package to easily recover. (4) it goes against FHS. read bug 493154 for details. there is absolutely no reason for an ebuild to install into /var. if an ebuild tries to, it's doing it wrong, and it's broken, and needlessly so. all that said, it's a moot point since iputils is removing tftpd support. so punting this request.
(In reply to SpanKY from comment #11) Interesting. If we are going to enforce that for /var/lib, the QA check should really get updated to include it.
