The packages target was previously listed under kernel, move it to the general source make targets listing. Add the update-packages target as well. Adjust the release building targets with package in their names to clarify they are unrelated to pkgbase. Add the OBJROOT and REPODIR variables to ENVIRONMENT. MFC after: 3 days Suggestions by: des, emaste, ivy, kevans, markj Fixes: 1d26746cfd4a (Document the packages target) Fixes: 0ac8aa55da1c (Add incremental packages) Fixes: 26490d9b74f0 (allow update-packages for first) Differential Revision: https://reviews.freebsd.org/D50289
Details
- Reviewers
mhorne carlavilla ivy markj 0mp - Group Reviewers
pkgbase manpages - Commits
- rGb15ef791f91f: build.7: Improve building pkgbase
rG7e8fb7756c3e: build.7: Improve building pkgbase
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
share/man/man7/build.7 | ||
---|---|---|
296 | the ABI dir is appended to REPODIR, so this should probably just be /usr/obj/${SRCDIR}/repo |
Does this fix it?
Also included, try to improve the release targets unrelated to pkgbase.
Thank you, this version is more useful.
share/man/man7/build.7 | ||
---|---|---|
295 | REPODIR's default value is /${OBJDIR}/${SRCDIR}/repo. It'd be useful to mention that. |
Thanks Mark, that's really great info!
I added that to the REPODIR description in ENVIRONMENT.
share/man/man7/build.7 | ||
---|---|---|
306 | “...unrelated to packaged base” or something like that; either way, “packages” should not be marked up since you are not directly referencing the target. | |
450 | “...unrelated to packaged base” or something like that; either way, “packages” should not be marked up since you are not directly referencing the target. | |
737 | “packages” should not be marked up since you are not directly referencing the target. | |
739 | I suggest you explain OBJROOT in a separate entry. |
share/man/man7/build.7 | ||
---|---|---|
285 | this could be rephased as "packages that can be used to install or upgrade the base system". | |
286 | there is no input repository | |
389 | i think this is trying to say that the repository can already exist if you ran (update-)packages before, but it's not very clear. "make packages" and "make update-packages" do the same thing up until the very end of the build: they create a new package repository in ${REPODIR}. the difference is that update-packages then copies some old packages from the previous repository version. | |
704 | instead of saying "pkg(7) targets", perhaps just say "packages". i don't think it's clear what a "pkg(7) target" is. there's one or two other instances of this. | |
734 | this is missing a word somewhere: right now it says setting REPODIR will create the repository, which is wrong, the repository is always created if you run make packages. perhaps change to "The root directory used to create the package repository for make packages", or something along those lines. |
share/man/man7/build.7 | ||
---|---|---|
389 | I do not know how to fix this. This is excessively complicated. That logic should be added to the packages target, while we can, and update-packages should really cease existing. |
share/man/man7/build.7 | ||
---|---|---|
389 | Then stop trying to make it complicated. :-) Create or update the .Xr packages 7 repository for the base system. If an old repository is being updated, then packages whose contents have not changed since the previous version will be copied into the new repository to avoid needless updating of the version number. .It Cm xdev-build ... Axe ", optionally created" altogether- that information is not at all necessary. |
aside from one or two stray instances of .Cm packages this looks good.
on (update-)packages: i've changed my mind a bit on this, we should keep both targets because there needs to be a way to just build packages from the current version of src without messing around with the previous build. however we definitely want to steer users towards using update-packages in any other docs about this. even committers aren't aware of this right now.