Closes: #29139
Rename bitcoin.conf to bitcoin.conf.example in the guix dist tarball. This avoids confusion that the file is actively used by the binary in bin/ without being renamed.
Closes: #29139
Rename bitcoin.conf to bitcoin.conf.example in the guix dist tarball. This avoids confusion that the file is actively used by the binary in bin/ without being renamed.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For detailed information about the code coverage, see the test coverage report.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Good idea, code review ACK 9256693be16cd56183557cf0bef57979fd04c39c
Thanks @fanquake
it's more correct to have it in the root directory to 1) make it easier for the user to find it and 2) be clear that it is not an example config but a full config
ls that dir looking for it personally...i think the point that it isn't actually used is a good one, and it would be good to make that clear, i see two options for that:
example (maybe better than share/example?)example in the file name, like bitcoin.conf.example@laanwj @willcl-ark for context, the original goals of having this file were:
bitcoin.conf from "someone on the internet"For 1, considering that we no longer provide an example config and it's fairly obvious when you open the file that it is a full config, I would prefer @laanwj 's suggestion of calling the file bitcoin.conf.example (I think all we would need to do then is update the docs where it prompts the user to copy the file to their datadir and mention it should be renamed to bitcoin.conf).
Not really a fan of moving the file into a different directory, since I think that makes the discoverability of the file slightly worse (which makes 2 more of a concern for me).
Ok there seems to be some push back here. Personally, I'd prefer to see files neatly in directories so that folks installing from a tarball directly into /usr/local wouldn't have random odds-and-ends ending up in the root there, but happy to conceed on this (perhaps I install binary tarballs weirdly?)
Seems like the path of least resistance is just to append .example, so I've done that here now.
I think all we would need to do then is update the docs where it prompts the user to copy the file to their datadir and mention it should be renamed to bitcoin.conf
I don't believe we have such instructions for the tarball, only for source-generated configs, which we are not not going to match directory-wise, so leaving this suggestion for now.
Personally, I'd prefer to see files neatly in directories so that folks installing from a tarball directly into /usr/local wouldn't have random odds-and-ends ending up in the root there
We still have the README.md in the root, so moving this file doesn't really address that concern. If there is a compelling argument for having nothing in the root, then I'd argue config/bitcoin.conf.example would make the most sense (as this is what I've seen for most other tarball distributed software projects).
LGTM, although the commit message and PR title still mention moving to share/examples
Motivated by #29139
Rename bitcoin.conf to bitcoin.conf.example in the guix dist tarball.
This avoids confusion that the file might be actively used by the
adjacent binaries in bin/ without being renamed.
If we change the name of the file, I think we should also include a dummy-proof instruction to remove .example when deploying the file, here:
@josibake @laanwj I'm happy to close this (and the issue) based on discussion above and in agreement with @pinheadmz comment on the issue, if you both agree?
Sure, if the outcome is "do nothing" that's optimal from our perspective. Enough serious issues...
Sure, if the outcome is "do nothing" that's optimal from our perspective. Enough serious issues...
+1.
Per #29903 (comment), it might make sense to revisit our tarball structure in the future and be in line with best practices for "installing by untarring into /usr/local", but I think that's a separate discussion so I'd suggest closing this for now.