aboutsummaryrefslogtreecommitdiff
path: root/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/content/en/books/porters-handbook/makefiles/_index.adoc')
-rw-r--r--documentation/content/en/books/porters-handbook/makefiles/_index.adoc12
1 files changed, 8 insertions, 4 deletions
diff --git a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
index e98d2ff336..bf37987160 100644
--- a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
@@ -1073,7 +1073,11 @@ In addition, proposed category changes just naturally seem to attract controvers
Here is the procedure:
[.procedure]
-. Propose the new category on {freebsd-ports}. Include a detailed rationale for the new category, including why the existing categories are not sufficient, and the list of existing ports proposed to move. (If there are new ports pending in Bugzilla that would fit this category, list them too.) If you are the maintainer and/or submitter, respectively, mention that as it may help the case.
+. Propose the new category on {freebsd-ports}. Include a detailed rationale
+ for the new category, including why the existing categories are not
+ sufficient, and the list of existing ports proposed to move. (If there are
+ new ports pending in Bugzilla that would fit this category, list them
+ too.) Indicating that the updater is also the maintainer or submitter may be helpful to the case.
. Participate in the discussion.
. If it seems that there is support for the idea, file a PR which includes both the rationale and the list of existing ports that need to be moved. Ideally, this PR would also include these patches:
@@ -1121,7 +1125,7 @@ If `DISTVERSION` does not derive a correct `PORTVERSION`, do not use `DISTVERSIO
====
If the upstream version scheme can be derived into a ports-compatible version scheme, set some variable to the upstream version, _do not_ use `DISTVERSION` as the variable name.
-Set `PORTVERSION` to the computed version based on the variable you created, and set `DISTNAME` accordingly.
+Set `PORTVERSION` to the computed version based on the created variable and set `DISTNAME` accordingly.
If the upstream version scheme cannot easily be coerced into a ports-compatible value, set `PORTVERSION` to a sensible value, and set `DISTNAME` with `PORTNAME` with the verbatim upstream version.
@@ -2202,7 +2206,7 @@ This is a very interesting feature which can decrease that endless search for th
Just picture 2 files in `DISTFILES` and 20 sites in `MASTER_SITES`, the sites slow as hell where [.filename]#beta# is carried by all sites in `MASTER_SITES`, and [.filename]#alpha# can only be found in the 20th site.
It would be such a waste to check all of them if the maintainer knew this beforehand, would it not? Not a good start for that lovely weekend!
-Now that you have the idea, just imagine more `DISTFILES` and more `MASTER_SITES`.
+Once the concept is clear, just imagine more `DISTFILES` and more `MASTER_SITES`.
Surely our "distfiles survey meister" would appreciate the relief to network strain that this would bring.
In the next sections, information will follow on the FreeBSD implementation of this idea.
@@ -2527,7 +2531,7 @@ This does not affect `MASTER_SITES` defined in the [.filename]#Makefile#.
[[makefile-maintainer]]
== `MAINTAINER`
-Set your mail-address here. Please. _:-)_
+Set the mail-address here. Please. _:-)_
Only a single address without the comment part is allowed as a `MAINTAINER` value.
The format used is `user@hostname.domain`.