Bug 215726 - [Patch] [RFE/feature request] allow an external patches directory for 3rd party patches.
Summary: [Patch] [RFE/feature request] allow an external patches directory for 3rd pa...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Port Management Team
URL:
Keywords: patch
Depends on: 215761
Blocks:
  Show dependency treegraph
 
Reported: 2017-01-03 10:58 UTC by Julian Elischer
Modified: 2017-05-21 18:28 UTC (History)
3 users (show)

See Also:


Attachments
diff against current ports (1.97 KB, patch)
2017-01-03 10:58 UTC, Julian Elischer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Elischer freebsd_committer freebsd_triage 2017-01-03 10:58:56 UTC
Created attachment 178469 [details]
diff against current ports

The reason for this is to allow a complete set of patches for a project to be held in a 3rd party repository on some unnamed source control system and applied as a single set. Possibly within poudriere. (I have not looked at synth but it should wok the same)

Having to apply the .local patches by hand in different directories gets too complex too fast.

Being able to set an environment variable to specify the patche set to apply simplifies incorporating the ports and packages into a 3rd party product.
to quote the patch:

+# EXTRA_PATCH_TREE - where to find extra 'out-of-tree' patches
+#                  Points to a directory hierarchy with the same layout
+#                  as the ports tree, where local patches can be found.
+#                  This allows a third party to keep their patches in
+#                  some other source control system if needed.

Does nothing if not defined.
 See the attached patch which had not changed in several years. (except line numbers).
Comment 1 Baptiste Daroussin freebsd_committer freebsd_triage 2017-01-03 12:35:59 UTC
I personally do like this idea it.

Actually I would even prefer an overlay system but that can be separated and come later (but I'm not portmgr so I let them decide :))

Note that I haven't reviewed the actually code, just the idea.
Comment 2 Mathieu Arnold freebsd_committer freebsd_triage 2017-01-03 13:24:19 UTC
I started rewriting the patch code during the holidays, I'll try to factor this in.
Comment 3 Julian Elischer freebsd_committer freebsd_triage 2017-01-04 06:29:17 UTC
let me know when you have a diff to see..

for what it's worth the patch included worked for a couple of years but is currently not being used because we tried to do it 'port-by-port' but that is turning out to be a bad idea so we are turning back to this one, and would love to have it upstream.
Comment 4 Mathieu Arnold freebsd_committer freebsd_triage 2017-01-04 07:39:04 UTC
Mmmm, I assumed as a subscriber to the review you'd have received an email, https://reviews.freebsd.org/D9029
Comment 5 Julian Elischer freebsd_committer freebsd_triage 2017-01-14 15:07:10 UTC
I need to merge in some stuff from freebsd ports this week, so if you are going to replace my version with another, it would be a good time for me to take it in and reduce the number of diffs I have to carry.

I am also considering a way to generate new local diffs in terms of a ports target

1  first apply standard diffs  (make patch)
2  make patch-snapshot
3  apply local diffs by hand
4  make local-patches
5  make remove-snapshot

patch-snapshot would copy the whole patch directory to one side in unpackacked and patched form. make local-patches would diff them
Comment 6 commit-hook freebsd_committer freebsd_triage 2017-01-16 16:48:18 UTC
A commit references this bug:

Author: mat
Date: Mon Jan 16 16:47:06 UTC 2017
New revision: 431681
URL: https://svnweb.freebsd.org/changeset/ports/431681

Log:
  Implement EXTRA_PATCH_TREE.

  PR:		215726
  Reported by:	julian

Changes:
  head/CHANGES
  head/Mk/Scripts/do-patch.sh
  head/Mk/bsd.port.mk