Differential D29450 Diff 86573 documentation/content/en/books/porters-handbook/upgrading/chapter.adoc
Changeset View
Changeset View
Standalone View
Standalone View
documentation/content/en/books/porters-handbook/upgrading/chapter.adoc
Show All 25 Lines | |||||||||
include::shared/en/mailing-lists.adoc[] | include::shared/en/mailing-lists.adoc[] | ||||||||
include::shared/en/teams.adoc[] | include::shared/en/teams.adoc[] | ||||||||
include::shared/en/urls.adoc[] | include::shared/en/urls.adoc[] | ||||||||
toc::[] | toc::[] | ||||||||
When a port is not the most recent version available from the authors, update the local working copy of [.filename]#/usr/ports#. The port might have already been updated to the new version. | When a port is not the most recent version available from the authors, update the local working copy of [.filename]#/usr/ports#. The port might have already been updated to the new version. | ||||||||
When working with more than a few ports, it will probably be easier to use Subversion to keep the whole ports collection up-to-date, as described in the link:{handbook}#ports-using/[Handbook]. This will have the added benefit of tracking all the port's dependencies. | When working with more than a few ports, it will probably be easier to use Git to keep the whole ports collection up-to-date, as described in the link:{handbook}#ports-using/[Handbook]. This will have the added benefit of tracking all the port's dependencies. | ||||||||
The next step is to see if there is an update already pending. To do this, there are two options. There is a searchable interface to the https://bugs.freebsd.org/search/[FreeBSD Problem Report (PR) or bug database]. Select `Ports & Packages` in the `Product` multiple select menu, and enter the name of the port in the `Summary` field. | The next step is to see if there is an update already pending. To do this, there are two options. There is a searchable interface to the https://bugs.freebsd.org/search/[FreeBSD Problem Report (PR) or bug database]. Select `Ports & Packages` in the `Product` multiple select menu, and enter the name of the port in the `Summary` field. | ||||||||
However, sometimes people forget to put the name of the port into the Summary field in an unambiguous fashion. In that case, try searching in the `Comment` field in the `Detailled Bug Information` section, or try the <<portsmon,FreeBSD Ports Monitoring System>> (also known as `portsmon`). This system attempts to classify port PRs by portname. To search for PRs about a particular port, use the http://portsmon.FreeBSD.org/portoverview.py[Overview of One Port]. | However, sometimes people forget to put the name of the port into the Summary field in an unambiguous fashion. In that case, try searching in the `Comment` field in the `Detailled Bug Information` section, or try the <<portsmon,FreeBSD Ports Monitoring System>> (also known as `portsmon`). This system attempts to classify port PRs by portname. To search for PRs about a particular port, use the http://portsmon.FreeBSD.org/portoverview.py[Overview of One Port]. | ||||||||
If there is no pending PR, the next step is to send an email to the port's maintainer, as shown by `make maintainer`. That person may already be working on an upgrade, or have a reason to not upgrade the port right now (because of, for example, stability problems of the new version), and there is no need to duplicate their work. Note that unmaintained ports are listed with a maintainer of `ports@FreeBSD.org`, which is just the general ports mailing list, so sending mail there probably will not help in this case. | If there is no pending PR, the next step is to send an email to the port's maintainer, as shown by `make maintainer`. That person may already be working on an upgrade, or have a reason to not upgrade the port right now (because of, for example, stability problems of the new version), and there is no need to duplicate their work. Note that unmaintained ports are listed with a maintainer of `ports@FreeBSD.org`, which is just the general ports mailing list, so sending mail there probably will not help in this case. | ||||||||
If the maintainer asks you to do the upgrade or there is no maintainer, then help out FreeBSD by preparing the update! Please do this by using the man:diff[1] command in the base system. | If the maintainer asks you to do the upgrade or there is no maintainer, then help out FreeBSD by preparing the update! Please do this by using the man:diff[1] command in the base system. | ||||||||
To create a suitable `diff` for a single patch, copy the file that needs patching to [.filename]#something.orig#, save the changes to [.filename]#something# and then create the patch: | To create a suitable `diff` for a single patch, copy the file that needs patching to [.filename]#something.orig#, save the changes to [.filename]#something# and then create the patch: | ||||||||
[source,shell] | [source,shell] | ||||||||
.... | .... | ||||||||
% diff -u something.orig something > something.diff | % diff -u something.orig something > something.diff | ||||||||
.... | .... | ||||||||
Otherwise, either use the `svn diff` method (<<svn-diff>>) or copy the contents of the port to an entire different directory and use the result of the recursive man:diff[1] output of the new and old ports directories (for example, if the modified port directory is called [.filename]#superedit# and the original is in our tree as [.filename]#superedit.bak#, then save the result of `diff -ruN superedit.bak superedit`). Either unified or context diff is fine, but port committers generally prefer unified diffs. Note the use of the `-N` option-this is the accepted way to force diff to properly deal with the case of new files being added or old files being deleted. Before sending us the diff, please examine the output to make sure all the changes make sense. (In particular, make sure to first clean out the work directories with `make clean`). | Otherwise, either use the `git diff` method (<<git-diff>>) or copy the contents of the port to an entire different directory and use the result of the recursive man:diff[1] output of the new and old ports directories (for example, if the modified port directory is called [.filename]#superedit# and the original is in our tree as [.filename]#superedit.bak#, then save the result of `diff -ruN superedit.bak superedit`). Either unified or context diff is fine, but port committers generally prefer unified diffs. Note the use of the `-N` option-this is the accepted way to force diff to properly deal with the case of new files being added or old files being deleted. Before sending us the diff, please examine the output to make sure all the changes make sense. (In particular, make sure to first clean out the work directories with `make clean`). | ||||||||
[NOTE] | [NOTE] | ||||||||
==== | ==== | ||||||||
If some files have been added, copied, moved, or removed, add this information to the problem report so that the committer picking up the patch will know what man:svn[1] commands to run. | If some files have been added, copied, moved, or removed, add this information to the problem report so that the committer picking up the patch will know what man:git[1] commands to run. | ||||||||
==== | ==== | ||||||||
To simplify common operations with patch files, use `make makepatch` as described in <<slow-patch,Patching>>. Other tools exists, like [.filename]#/usr/ports/Tools/scripts/patchtool.py#. Before using it, please read [.filename]#/usr/ports/Tools/scripts/README.patchtool#. | To simplify common operations with patch files, use `make makepatch` as described in <<slow-patch,Patching>>. Other tools exists, like [.filename]#/usr/ports/Tools/scripts/patchtool.py#. Before using it, please read [.filename]#/usr/ports/Tools/scripts/README.patchtool#. | ||||||||
If the port is unmaintained, and you are actively using it, please consider volunteering to become its maintainer. FreeBSD has over 4000 ports without maintainers, and this is an area where more volunteers are always needed. (For a detailed description of the responsibilities of maintainers, refer to the section in the link:{developers-handbook}#POLICIES-MAINTAINER[Developer's Handbook].) | If the port is unmaintained, and you are actively using it, please consider volunteering to become its maintainer. FreeBSD has over 4000 ports without maintainers, and this is an area where more volunteers are always needed. (For a detailed description of the responsibilities of maintainers, refer to the section in the link:{developers-handbook}#POLICIES-MAINTAINER[Developer's Handbook].) | ||||||||
To submit the diff, use the https://bugs.freebsd.org/submit/[bug submit form] (product `Ports & Packages`, component `Individual Port(s)`). Always include the category with the port name, followed by colon, and brief descripton of the issue. Examples: `_category/portname_: _add FOO option_`; `_category/portname_: _Update to X.Y_`. Please mention any added or deleted files in the message, as they have to be explicitly specified to man:svn[1] when doing a commit. Do not compress or encode the diff. | To submit the diff, use the https://bugs.freebsd.org/submit/[bug submit form] (product `Ports & Packages`, component `Individual Port(s)`). Always include the category with the port name, followed by colon, and brief descripton of the issue. Examples: `_category/portname_: _add FOO option_`; `_category/portname_: _Update to X.Y_`. Please mention any added or deleted files in the message, as they have to be explicitly specified to man:git[1] when doing a commit. Do not compress or encode the diff. | ||||||||
Before submitting the bug, review the link:{problem-reports}#pr-writing/[ Writing the problem report] section in the Problem Reports article. It contains far more information about how to write useful problem reports. | Before submitting the bug, review the link:{problem-reports}#pr-writing/[ Writing the problem report] section in the Problem Reports article. It contains far more information about how to write useful problem reports. | ||||||||
[IMPORTANT] | [IMPORTANT] | ||||||||
==== | ==== | ||||||||
If the upgrade is motivated by security concerns or a serious fault in the currently committed port, please notify the {portmgr} to request immediate rebuilding and redistribution of the port's package. Unsuspecting users of `pkg` will otherwise continue to install the old version via `pkg install` for several weeks. | If the upgrade is motivated by security concerns or a serious fault in the currently committed port, please notify the {portmgr} to request immediate rebuilding and redistribution of the port's package. Unsuspecting users of `pkg` will otherwise continue to install the old version via `pkg install` for several weeks. | ||||||||
==== | ==== | ||||||||
[NOTE] | [NOTE] | ||||||||
==== | ==== | ||||||||
Please use man:diff[1] or `svn diff` to create updates to existing ports. Other formats include the whole file and make it impossible to see just what has changed. When diffs are not included, the entire update might be ignored. | Please use man:diff[1] or `git diff` to create updates to existing ports. Other formats include the whole file and make it impossible to see just what has changed. When diffs are not included, the entire update might be ignored. | ||||||||
==== | ==== | ||||||||
Now that all of that is done, read about how to keep up-to-date in <<keeping-up,Keeping Up>>. | Now that all of that is done, read about how to keep up-to-date in <<keeping-up,Keeping Up>>. | ||||||||
[[svn-diff]] | [[git-diff]] | ||||||||
== Using Subversion to Make Patches | == Using Git to Make Patches | ||||||||
When possible, please submit a man:svn[1] diff. They are easier to handle than diffs between "new and old" directories. It is easier to see what has changed, and to update the diff if something was modified in the Ports Collection since the work on it began, or if the committer asks for something to be fixed. Also, a patch generated with `svn diff` can be easily applied with `svn patch` and will save some time to the committer. | When possible, please submit a man:git[1] diff. They are easier to handle than diffs between "new and old" directories. It is easier to see what has changed, and to update the diff if something was modified in the Ports Collection since the work on it began, or if the committer asks for something to be fixed. Also, a patch generated with `git diff` can be easily applied with `git apply` and will save some time to the committer. | ||||||||
[source,shell] | [source,shell] | ||||||||
.... | .... | ||||||||
% cd ~/my_wrkdir <.> | % cd ~/my_ports_wrkdir <.> | ||||||||
% svn co https://svn.FreeBSD.org/ports/head/dns/pdnsd <.> | % git clone https://cgit.FreeBSD.org/ports.git <.> | ||||||||
% cd ~/my_wrkdir/pdnsd | % cd ~/my_wrkdir/dns/pdnsd | ||||||||
.... | .... | ||||||||
<.> This can be anywhere, of course. Building ports is not limited to within [.filename]#/usr/ports/#. | <.> This can be anywhere, of course. Building ports is not limited to within [.filename]#/usr/ports/#. | ||||||||
<.> https://svn.FreeBSD.org/[svn.FreeBSD.org] is the FreeBSD public Subversion server. See link:{handbook}#svn-mirrors[Subversion mirror sites] for more information. | <.> https://cgit.FreeBSD.org/[cgit.FreeBSD.org] is the FreeBSD public Git server. See link:{handbook}#svn-mirrors[Subversion mirror sites] for more information. | ||||||||
While in the port directory, make any changes that are needed. If adding, copying, moving, or removing a file, use `svn` to track these changes: | While in the port directory, make any changes that are needed. If adding, moving, or removing a file, use `git` to track these changes: | ||||||||
[source,shell] | [source,shell] | ||||||||
.... | .... | ||||||||
% svn add new_file | % git add new_file | ||||||||
% svn copy some_file file_copy | % git mv old_name new_name | ||||||||
% svn move old_name new_name | % git rm deleted_file | ||||||||
% svn remove deleted_file | |||||||||
.... | .... | ||||||||
Make sure to check the port using the checklist in <<porting-testing,Testing the Port>> and <<porting-portlint,Checking the Port with `portlint`>>. | Make sure to check the port using the checklist in <<porting-testing,Testing the Port>> and <<porting-portlint,Checking the Port with `portlint`>>. | ||||||||
[source,shell] | [source,shell] | ||||||||
.... | .... | ||||||||
% svn status | % git status --short | ||||||||
% svn update <.> | % git pull --rebase <.> | ||||||||
.... | .... | ||||||||
<.> This will attempt to merge the differences between the patch and current repository version. Watch the output carefully. The letter in front of each file name indicates what was done with it. See <<table-svn-up>> for a complete list. | <.> This will attempt to merge the differences between the patch and current repository version. Watch the output carefully. The letter in front of each file name indicates what was done with it. | ||||||||
mat: All this is no longer valid, when you git pull, it will fetch the new changes, and then it will… | |||||||||
[[table-svn-up]] | |||||||||
.Subversion Update File Prefixes | |||||||||
[cols="10%,90%", frame="none"] | |||||||||
|=== | |||||||||
|U | |||||||||
|The file was updated without problems. | |||||||||
|G | |||||||||
|The file was updated without problems (only when working against a remote repository). | |||||||||
|M | |||||||||
|The file had been modified, and was merged without conflicts. | |||||||||
|C | |||||||||
|The file had been modified, and was merged with conflicts. | |||||||||
|=== | |||||||||
If `C` is displayed as a result of `svn update`, it means something changed in the Subversion repository and man:svn[1] was not able to merge the local changes with those from the repository. It is always a good idea to inspect the changes anyway, since man:svn[1] does not know anything about the structure of a port, so it might (and probably will) merge things that do not make sense. | |||||||||
The last step is to make a unified man:diff[1] of the changes: | The last step is to make a unified man:diff[1] of the changes: | ||||||||
[source,shell] | [source,shell] | ||||||||
.... | .... | ||||||||
% svn diff > ../`make -VPKGNAME`.diff | % git diff . > ../`make -VPKGNAME`.diff | ||||||||
Done Inline Actions
git diff will always diff the whole repository, not the current directory. mat: git diff will always diff the whole repository, not the current directory. | |||||||||
.... | .... | ||||||||
[NOTE] | [NOTE] | ||||||||
==== | ==== | ||||||||
If files have been added, copied, moved, or removed, include the man:svn[1] `add`, `copy`, `move`, and `remove` commands that were used. `svn move` or `svn copy` must be run before the patch can be applied. `svn add` or `svn remove` must be run after the patch is applied. | If files have been added, moved, or removed, include the man:git[1] `add`, `mv`, and `rm` commands that were used. `git mv` must be run before the patch can be applied. `git add` or `git rm` must be run after the patch is applied. | ||||||||
==== | ==== | ||||||||
Send the patch following the link:{problem-reports}#pr-writing/[problem report submission guidelines]. | Send the patch following the link:{problem-reports}#pr-writing/[problem report submission guidelines]. | ||||||||
[[moved-and-updating-files]] | [[moved-and-updating-files]] | ||||||||
== [.filename]#UPDATING# and [.filename]#MOVED# | == [.filename]#UPDATING# and [.filename]#MOVED# | ||||||||
[[moved-and-updating-updating]] | [[moved-and-updating-updating]] | ||||||||
▲ Show 20 Lines • Show All 65 Lines • Show Last 20 Lines |
All this is no longer valid, when you git pull, it will fetch the new changes, and then it will either do nothing with an error if you have uncommitted changes, or try to merge the changes, which can fail with merge conflicts, but in any way, merging is not a good idea. One should run git pull --rebase to make sure no merge commits are introduced.