https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226290
--- Comment #5 from Kubilay Kocak <ko...@freebsd.org> --- (In reply to dereks from comment #4) pkg-descr: long_description, formatted well, if there is one. otherwise some upstream source that provides a nice initial summary, formatted nicely if necessary. if no upstream source exists, creative license/common sense and send them a PR to add it :) TEST_DEPENDS: These dont block landing your changes, but its good to get into the habit of adding test framework bits (TEST_DEPENDS/test: target) early. conflicts/conncurrency: USE_PYTHON=concurrent should handle most if not all of it. It definitely handles stuff installed in LOCALBASE/bin. Re testing/building with other python versions: - In LOCALBASE/etc/poudriere.d/py36.conf - Add DEFAULT_VERSIONS=python=x.y - poudriere testport -o <origin> -z py36 You can create as many *.conf's as you want, and use them in -z <set> args. Ignore the symlinks in those cases, the framework does the right thing for the (ports) users DEFAULT_VERSIONN, and for package users, we only produce packages for the default default_Version (2.7), so 3.x packages (if they were built), wont contain them. patches: Generally, ideally yes, less maintenance long term, relationship++ with upstreams. In this patches case, its a hardcoded default. The package could support some form of configuration that can be set at build time so the right (custom) path is set wherever it needs to be. The post-patch is fine for now. The upstream issue summary might look something like "Provide mechanism to replace hardcoded /etc dir" or similar -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
