Created attachment 143848 [details] Patch for updating py-stl 3.1 to stltools 3.2. The name py-stl didn't fit very well with the way FreeBSD names python ports. So I decided to rename it to stltools. This version 3.2 now uses numpy, and the port Makefile was re-written from scratch to work with staging and building a package as a non-root user. Tested with "env DEVELOPER=yes make stage && make check-plist && make package".
I get plist issues in poudriere: ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist Error: Orphaned: %%PYTHON_SITELIBDIR%%/stltools-3.2-py2.7.egg-info/PKG-INFO Error: Orphaned: %%PYTHON_SITELIBDIR%%/stltools-3.2-py2.7.egg-info/SOURCES.txt Error: Orphaned: %%PYTHON_SITELIBDIR%%/stltools-3.2-py2.7.egg-info/dependency_links.txt Error: Orphaned: %%PYTHON_SITELIBDIR%%/stltools-3.2-py2.7.egg-info/top_level.txt Error: Orphaned: @dirrmtry %%PYTHON_SITELIBDIR%%/stltools-3.2-py2.7.egg-info ===> Checking for directories owned by MTREEs ===> Checking for directories handled by dependencies ===> Checking for items in pkg-plist which are not in STAGEDIR ===> Error: Plist issues found. *** [check-plist] Error code 1 Stop in /usr/ports/graphics/py-stl. ====>> Error: check-plist failures detected Can you take a look?
Created attachment 144626 [details] Updated patch to fix plist orphans.
Hello Roland, the new patch seems to work fine, no stage orphans are left, thanks! However, regarding the renaming I would like to clarify things, so we can decide on what is the most sensible approach here. On the stltools homepage you explain the renaming: "Programs that require an interpreter are prefixed with its name and version. So py-stl would become py27-py-stl, which would be silly." This is not quite accurate. Not all programs that _require_ an interpreter use this prefix, but those whose primary purpose is to _extend_ said interpreter. To give you an example for each of those: - math/py-numpy does not install much stuff that can be used by itself. Instead it is supposed to extend the capabilities of the system wide python installation. Because of this, it is placed in the "py-numpy" folder, uses PYTHON_PKGNAMEPREFIX and thus will be (typical installation, as of today) installed as py27-numpy-1.8.1,1 - multimedia/quodlibet is intended to be used as a standalone application that is started via desktop or from a terminal. Its primary purpose is NOT extending the power of the system wide python installation but standalone usage. That's why it is neither placed in multimedia/py-quodlibet nor does it use PYTHON_PKGNAMEPREFIX. As a consequence, it will be installed (again, typical installation, as of today) simply as quodlibet-2.6.3 So the question really is, what is the primary purpose of your package. If it is to be used as standalone tools, I would suggest we place it in graphics/stltools and remove PYTHON_PKGNAMEPREFIX from the Makefile. Otherwise I'd place it in graphics/py-stltools and keep PYTHON_PKGNAMEPREFIX. Let me know what you think. Best wishes Riggs
Riggs, Thanks for the clarification. I hadn't realized what the purpose of PYTHON_PKGNAMEPREFIX was. There is an stltools package in there which contains the pieces (like reading and writing STL files, vector operations and the like) that are shared amongst the tools and can be used for other programs. But the _primary_ purpose is to be a suite of standalone tools, not related to the Python interpreter itself. So naming it graphics/stltools seems the way to go. One remaining question w.r.t. the PYTHON_PKGNAMEPREFIX, though. With the recent work on installing a Python-based package for different Python versions, isn't the prefix needed for that as well? As soon as that support matures and I can have e.g. numpy and cairo installed for Python 3.x, I'm planning to switch my ports over to use Python 3. (In reply to Thomas Zander from comment #3) > Hello Roland, > > the new patch seems to work fine, no stage orphans are left, thanks! > > However, regarding the renaming I would like to clarify things, so we can > decide on what is the most sensible approach here. On the stltools homepage > you explain the renaming: > > "Programs that require an interpreter are prefixed with its name and > version. So py-stl would become py27-py-stl, which would be silly." > > This is not quite accurate. Not all programs that _require_ an interpreter > use this prefix, but those whose primary purpose is to _extend_ said > interpreter. To give you an example for each of those: > - math/py-numpy does not install much stuff that can be used by itself. > Instead it is supposed to extend the capabilities of the system wide python > installation. Because of this, it is placed in the "py-numpy" folder, uses > PYTHON_PKGNAMEPREFIX and thus will be (typical installation, as of today) > installed as py27-numpy-1.8.1,1 > - multimedia/quodlibet is intended to be used as a standalone application > that is started via desktop or from a terminal. Its primary purpose is NOT > extending the power of the system wide python installation but standalone > usage. That's why it is neither placed in multimedia/py-quodlibet nor does > it use PYTHON_PKGNAMEPREFIX. As a consequence, it will be installed (again, > typical installation, as of today) simply as quodlibet-2.6.3 > > So the question really is, what is the primary purpose of your package. If > it is to be used as standalone tools, I would suggest we place it in > graphics/stltools and remove PYTHON_PKGNAMEPREFIX from the Makefile. > Otherwise I'd place it in graphics/py-stltools and keep PYTHON_PKGNAMEPREFIX. > > Let me know what you think. > Best wishes > Riggs
Yes, the port does install files into PYTHON_SITELIBDIR, so it extends the python installation with new functionality. In order to do that with different versions, we need to keep the prefix, that is correct. So the best way is to rename it to py-stltools and keep the prefix. I'll take care of it, thank you for your quick response and explanation of your plans.
A commit references this bug: Author: riggs Date: Sun Jul 13 16:09:02 UTC 2014 New revision: 361692 URL: http://svnweb.freebsd.org/changeset/ports/361692 Log: - Move graphics/py-stl to graphics/py-stltools (project has been renamed) - Update to upstream version 3.2 - Stagify - Makefile cleanup / Pet portlint PR: 191103 Submitted by: Roland Smith <rsmith@xs4all.nl> (maintainer) Approved by: mentors (implicit) Changes: head/MOVED head/graphics/py-stl/ head/graphics/py-stltools/ head/graphics/py-stltools/Makefile head/graphics/py-stltools/distinfo head/graphics/py-stltools/pkg-descr head/graphics/py-stltools/pkg-plist
Committed with minor modifications, thanks!
A commit references this bug: Author: riggs Date: Sun Jul 13 19:41:31 UTC 2014 New revision: 361706 URL: http://svnweb.freebsd.org/changeset/ports/361706 Log: - Add missing entry in graphics/Makefile after moving py-stl to py-stltools PR: 191103 Submitted by: Roland Smith <rsmith@xs4all.nl> (maintainer) Approved by: mentors (implicit) Changes: head/graphics/Makefile