The section of the Handbook that documents building from source is byzantine and bizarre, disjointed and difficult to follow. Rip it out by the roots and start over. This rewrite shows etcupdate as preferred to mergemaster. It begins with a Quick Start to summarize the process. Later sections add more detail. Some sections need more details, like the ones lacking any detail at all.
Details
- Reviewers
jhb woodsb02 rpokala imp bdrewery - Group Reviewers
Doc Committers - Commits
- rD50251: Rewrite the Build from Source section, simplifying and clarifying.
Repeat until adequate to commit:
Rewrite document. Show to people. Hope they will help fix flaws. Fix flaws.
Rendered preview version: http://www.wonkity.com/~wblock/tmp/updating/updating-src.html
Diff Detail
- Repository
- rD FreeBSD doc repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Warren, thank you for working on this and including etcupdate. I've added a few comments of my own.
cutting-edge/chapter.xml | ||
---|---|---|
1099 ↗ | (On Diff #19733) | s/computer/FreeBSD system/ |
1173 ↗ | (On Diff #19733) | Maybe mention which step to jump to when not doing to the first time? Something like "If etcupdate extract has been performed before, continue with step X." |
1185 ↗ | (On Diff #19733) | Ensure that svn is installed first or provide svnlite as an alternative? |
1317 ↗ | (On Diff #19733) | Yes, we should describe the boring, default way of doing it here and not get lost in fancy optimizations. Things like MODULES_OVERRIDE and src.conf entries can easily be on their own (next) page. devel/ccache can also be mentioned there, but not here. |
1348 ↗ | (On Diff #19733) | I'm thinking whether we should describe this here or not. Like I wrote above, it can distract from the standard, boring default way. People who want to it more advanced should refer to that section. |
cutting-edge/chapter.xml | ||
---|---|---|
1095 ↗ | (On Diff #19733) | step 1 should be making sure you have a src checkout. Since this is quick start, it might be worth duplicating the bit about how to check out the src from the appendix. |
1118 ↗ | (On Diff #19733) | this should be buildkernel |
1119 ↗ | (On Diff #19733) | kernel should be installed first, and the system rebooted onto the new kernel, before installing the newer world. Otherwise things like top/ps might break. |
1154 ↗ | (On Diff #19733) | you didn't actually install the kernel |
cutting-edge/chapter.xml | ||
---|---|---|
1118 ↗ | (On Diff #19733) | The kernel target is buildkernel + installkernel. |
1119 ↗ | (On Diff #19733) | top or ps would only be broken until the final/only reboot, the last step in the process. So that would be kind of self-inflicted by the reader not following the procedure. Ideally, I'd like to make this quick start even shorter, preferably no more than three steps. Refinements can be explained in the detail sections that come later. |
1154 ↗ | (On Diff #19733) | Did too! kernel is buildkernel + installkernel. The idea here is to boil the 384-step procedure into as few steps as possible. |
1173 ↗ | (On Diff #19733) | If possible, this step should be removed entirely. My experience is that people will perform steps as shown, even if it says not to do it. So the question is: can etcupdate be like mergemaster, and figure out when it is being run for the first time? |
1185 ↗ | (On Diff #19733) | All of the svnlite help pages refer to svn, because it really is svn. Rather than try to document all the other possible ways to do things, this guide tries to pick just the preferred method. So svn is preferred because it will be up to date, where svnlite is in base and it's impossible to tell how obsolete it might be. |
1317 ↗ | (On Diff #19733) | Yes. Of course, the build system has big differences between 10.x and 11.x, so that is a challenge. |
1348 ↗ | (On Diff #19733) | Mainly it is here because it is such a common concern. Putting it here keeps it out of the quick start. |
Hi Warren,
Nice work getting this draft done and up for review - apologies I haven't helped more to date.
I really like this simplification, so please don't take the number of my comments as meaning I am negative towards this work - I like it and just want to ensure it is both concise and accurate.
cutting-edge/chapter.xml | ||
---|---|---|
1071 ↗ | (On Diff #19733) | Why rip out the section that describes what FreeBSD-STABLE is? In my mind this should stay, as it immediately follows the description of FreeBSD-CURRENT, and is referred to in the first paragraph after the title "Tracking a Development Branch". Refer here for how it looks today: https://www.freebsd.org/doc/handbook/current-stable.html |
1095 ↗ | (On Diff #19733) | Just to clarify, checking /usr/src/UPDATING should only be done after the source has been updated. Hence, checking /usr/src/UPDATING should instead be a step after "svn update" and before "make -j4 buildworld". |
1095 ↗ | (On Diff #19733) | What the user can and should do at this early stage, is:
|
1109 ↗ | (On Diff #19733) | This is true as long as the user does each and every update using etcupdate(8) to merge the configuration files. If a user does a binary update, or a source update using the alternative mergemaster(8), then the etcupdate(8) stored checkpoint will be out of date and will need to be re-bootstrapped by once again running "etcupdate extract" using a version of the source tree which matches the currently running system. |
1115 ↗ | (On Diff #19733) | Might be cleaner to instruct the user to "cd /usr/src" and then "svn update", followed by other commands that need /usr/src to be the working directory. |
1117 ↗ | (On Diff #19733) | Should we prompt users to save the output of the build by either first running script(1) or piping the output to tee(1)? This will allow them to review the output later in case of any errors, and post it to the mailing lists if seeking help. Perhaps this could be added to the detailed section below... but as you said, if you want people to do it, it should be in the quick start. |
1141 ↗ | (On Diff #19733) | This should say "Compile and install the kernel." |
1165 ↗ | (On Diff #19733) | Again, checking /usr/src/UPDATING should be done after "svn update". |
1172 ↗ | (On Diff #19733) | During an extract, etcupdate is not making a record of the system settings, it is making a record of the default configuration files (as they would be installed from the source tree) in the pre-update state. Since it is performing a 3-way merge, etcupdate needs 3 copies of the source to be able to determine how to perform the merge: the pre-update default version (from the source tree before "svn update"), the post-update default version (from the source tree after "svn update"), and the as-installed version (from /etc/). "etcupdate extract" is creating a record of the pre-update default versions, since when the user runs the "etcupdate" command from /usr/src post-update, the pre-update copy will not otherwise be available on the system for comparison and 3-way merge. |
1173 ↗ | (On Diff #19733) | The difficult thing for etcupdate to determine is, is the configuration file in /etc different from the one in /usr/src because the user edited it, or because the default version in the source tree has changed. When you first install FreeBSD, it actually comes with a copy of the etcupdate checkpoint pre-populated with the as-installed source... so this "etcupdate extract" command is not technically required when performing the FIRST update. The tricky part is when this is the first time the user has used etcupdate to perform post-update configuration file merging, but has performed previous binary updates or source updates using mergemaster(8), and therefore the pre-populated etcupdate checkpoint is out of date, and will lead to incorrect 3-way merges. This scenario is when the user really needs to re-bootstrap via the "etcupdate extract" command. Each time etcupdate is used for merging, it saves a copy of the source tree configuration files used for comparison with the next time. Hence why it is said the "etcupdate extract" is only required the first time. If the user wishes to check if the current etcupdate checkpoint is accurate, they should run "etcupdate diff" and confirm that the output correctly reflects each of their local /etc changes/customizations over the default version from the source tree, and no other changes. |
1202 ↗ | (On Diff #19733) | Rather than repeating it, perhaps this should reference the existing section of the appendix which explains how to use subversion to checkout source? |
1332 ↗ | (On Diff #19733) | I would tend to use "rm -rf /usr/obj/*" to avoid removing the top directory of /usr/obj itself. This is because I tend to have that directory mounted as a separate zfs dataset. Without needing to describe the reasons for this, "rm -rf /usr/obj/*" may just cater for more use-cases. |
1332 ↗ | (On Diff #19733) | Is it still the case that some files in the build directories may be set as immutable, and therefore "chflags -R noschg /usr/obj/*" may first be required? I have not needed this in a long time... |
1341 ↗ | (On Diff #19733) | This section should explain how "make buildkernel" differs from "make kernel" (which was the basic step given above). |
1372 ↗ | (On Diff #19733) | Perhaps also mention that instead of copying GENERIC (which means your custom config will not automatically receive any future changes to GENERIC), you can instead create a small custom kernel config that begins with the line "include GENERIC" and then has subsequent lines which overwrite the GENERIC kernel config. |
1399 ↗ | (On Diff #19733) | Perhaps clarify that "installkernel" is only needed if "buildkernel" was used instead of "kernel" |
1444 ↗ | (On Diff #19733) | Perhaps also mention you can use "make -DBATCH_DELETE_OLD_FILES delete-old" if you don't want to be prompted for each file that will be deleted. |
1461 ↗ | (On Diff #19733) | Again, "make -DBATCH_DELETE_OLD_FILES delete-old-libs" can be used if you don't want to be prompted for each file that will be deleted. |
A much needed refresh for a very frequently referenced page. Good stuff!
cutting-edge/chapter.xml | ||
---|---|---|
1141 ↗ | (On Diff #19733) | It might be good to call out "make installkernel" separately as its useful for installing custom kernels even if it's included as part of installworld (Is it - I didn't know that). Its good feedback for the user to let them they they can do it. Doesn't affect the quick start approach. |
1154 ↗ | (On Diff #19733) | +1 allanjude wblock: your text is shorter but omitting installkernel seems cutting down on too much info. One extra line won't affect the quick start more importantly because its a crucial step. |
1247 ↗ | (On Diff #19733) | The references to 10.3-release: is there a way to link to the current release automatically? New users might see 11 being the latest and greatest advertised everywhere and might think this doc is out of date. Just a suggestion. |
1282 ↗ | (On Diff #19733) | Should be make buildkernel to match rest of text |
1320 ↗ | (On Diff #19733) | I would suggest we move this above before starting build. Most users would want to remove the obj directory before starting a clean build. |
1414 ↗ | (On Diff #19733) | A description of etcupdate and mergemaster would be useful, specifically noting that the user doesn't need to do both (if that's the case). |
1424 ↗ | (On Diff #19733) | This should be wrapped in <screen></screen>? |
1431 ↗ | (On Diff #19733) | This should be wrapped in <screen></screen>? |
cutting-edge/chapter.xml | ||
---|---|---|
1071 ↗ | (On Diff #19733) | It is wordy and confusing. I'll add a third column to the table in the Updating the Source section that briefly describes each branch. |
1095 ↗ | (On Diff #19733) |
This is meant to be a reminder of the standard steps rather than the exceptions. Maybe it should not be called a quick start, but an overview.
These details are also better in the later sections where they will not obscure the basic steps. |
1099 ↗ | (On Diff #19733) | I don't understand what you are saying here. Is the distinction that we might be in a VM or a multi-boot system rather than on a FreeBSD-only computer? |
1109 ↗ | (On Diff #19733) | This would be better mentioned in the detail sections below. In a section where we only show using etcupdate, it is a distraction to warn the user against using something we did not show. |
1115 ↗ | (On Diff #19733) | It would save a little typing, but I feel that explicitly giving the directory in the update command is useful to illustrate which directory is being acted on. |
1117 ↗ | (On Diff #19733) | Detail section would be better. |
1141 ↗ | (On Diff #19733) | There is a bit about this in the detail section. |
1154 ↗ | (On Diff #19733) | The kernel is installed. The "it's just a wafer-thin mint" approach ends up with a long, detailed list of instructions like the old version of this document, where it is too big to remember and has many exceptions that do not matter to the typical user. All of that details, or rather the part of it that is required, can go in the detail sections that come later in this chapter. |
1172 ↗ | (On Diff #19733) | The challenge is to explain it to the reader without so much detail that it clouds the explanation. |
1202 ↗ | (On Diff #19733) | I wrote some of that, but it is vague and not specific to the purposes here. Also, I have wanted for a while to split all the Subversion stuff out of at least four of our books into a single Subversion for FreeBSD book. Not that I've done it, but still. |
1247 ↗ | (On Diff #19733) | We have entities for OS release version numbers, but not separate entities for major and minor version numbers, as far as I'm aware. |
1320 ↗ | (On Diff #19733) | Moved to the start of the "additional options", but not before the "basic steps" section. Deleting /usr/obj is hardly ever necessary in any case. |
1332 ↗ | (On Diff #19733) | The build scripts do it. At least it has been years since I've done it, so no, it is no longer required on 10, 11, or 12. |
1341 ↗ | (On Diff #19733) | Added a note to the callouts in the quick start to cover this. |
1372 ↗ | (On Diff #19733) | That can be added as one of these special options section. I considered showing the good method of creating the kernel config file in /root and linking it into /usr/src, so it does not go away when /usr/src is deleted. But that can also be a section added later. |
1399 ↗ | (On Diff #19733) | Changed the long form instructions to use buildkernel, so this matches. |
1414 ↗ | (On Diff #19733) | This needs to be expanded, yes. And I'm considering removing mergemaster entirely. But I still do not have a feel for etcupdate. It seems relatively "smart" and is probably the only thing to recommend. If only there were some easy way to explain three-way merges, or in fact, any kind of merges to the average reader. Getting away from horrible old-style non-unified diffs is a start. |
1424 ↗ | (On Diff #19733) | It's just a placeholder screaming "expound here!" |
1431 ↗ | (On Diff #19733) | As is/was this... but it's on borrowed time. |
1444 ↗ | (On Diff #19733) | Or just yes | make delete-old if you don't care about how the screen looks afterward. |
1454 ↗ | (On Diff #19733) | I would really, really like to know how to do this. Even the current docs tell the reader "Yes, delete these old libraries! Oh, but it might mean some of your old programs no longer work. Better yet, there is no way to tell which!" Probably the way to address this is to say that if any old programs no longer work, they must just be recompiled. |
1461 ↗ | (On Diff #19733) | The more modern notation would be make BATCH_DELETE_OLD_FILES=yes delete-old-libs, but I have not tried it. It makes the command much more intimidating. Maybe a single tip to mention this... |
Perhaps not on this page, but somewhere it would be nice to mention 'etcupdate diff'.
cutting-edge/chapter.xml | ||
---|---|---|
1098 ↗ | (On Diff #20883) | FYI, if you have done a fresh install of 10.1 or later then this step is not necessary. Put another way, you should only have to do this for the first upgrade from 10.0 or earlier. (You don't need it for 9.3 either it turns out, but 10.0 and older is probably a simpler way of saying it). |
1116 ↗ | (On Diff #20883) | You may need to include 'etcupdate -p' as a step between 'make buildworld' and 'make kernel'. It is rarely needed, but you can get installworld/installkernel failures if those need a newly added user or group. |
1446 ↗ | (On Diff #20883) | I think it should be clear that you use either etcupdate or mergemaster, but not both. I'd hate to confuse users. It is probably worth mentioning running 'etcupdate resolve' to resolve any conflicts reported by 'etcupdate'. |
cutting-edge/chapter.xml | ||
---|---|---|
1454 ↗ | (On Diff #19733) | You can grep for the names of the old libraries in the output of procstat -af -- needs a bit of scripting to pull out the process name for each PID, but that's not difficult. Obviously this only picks out processes that are actually being run, but even so, it is pretty effective. |
Removed mention of etcupdate, leaving that for someone who actually uses it. Switch from deleting /usr/obj to using 'make cleanworld' on advice of bdrewery.
Etcupdate was the main improvement (for me) in this change :-(.
I use it, but don't know if I'm doing it correctly or not. I skip mergemaster -p entirely. Here is what I use in place of mergemaster -iF:
etcupdate -F -s /path/to/my/src/tree
I don't recall if I had to do any initial setup for etcupdate, but I believe I may have.
Here's what I did recently using etcupdate for the first time (worked flawlessly, will use it in the future like this):
- Bootstrap etcupdate (only needed once). Do this before upgrading your kernel sources (in /usr/src):
etcupdate extract
- Update the src tree in /usr/src, followed by (-j option omitted for simplicity)
make buildworld make kernel
- In single user mode, install the world via
make installworld
- Now, simply run
etcupdate
- (optional)
make check-old && yes|make delete-old && yes|make delete-old-libs
- reboot into multi-user mode, done!
There is also an EXAMPLES section in etcupdate(8). Thanks for doing the work, it is definitely an improvement of the chapter!
In reply to @bcr: For modern releases (10.0 and later I think), etcupdate is now bootstrapped during an install, so you can skip that first step on fresh installs. You can use 'etcupdate diff' to verify if you need to extract or not.
Sorry about that. This rewrite has been held up way too long, and the situation was made worse recently by minor edits to the old version, subsequent merge conflicts, and Subversion "helping". The new layout is modular and instructions for etcupdate can be added by someone who uses it. I tried it, and think the merge functionality might be nice, but it did not seem to be a full replacement for mergemaster. For instance, it did not update MOTD. I might have been using it wrong, but don't expect to have more time to work on it any time soon.
Understood! I don't mean to complain too much. There's no need to fix everything at once; monotonic improvement is sufficient :-).