| Summary: | app-benchmarks/s-tui-0.8.3-1 - Terminal UI stress test and monitoring tool | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Antoine Gicquel <antoine.gicquel> |
| Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | fedeliallalinea |
| Priority: | Normal | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/amanusk/s-tui | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | s-tui-0.8.3-1.ebuild | ||
|
Description
Antoine Gicquel
2019-03-06 22:11:03 UTC
Comment on attachment 568074 [details] s-tui-0.8.3-1.ebuild ># Copyright 1999-2019 Gentoo Foundation ># Distributed under the terms of the GNU General Public License v2 > >EAPI=7 > >DESCRIPTION="Terminal UI stress test and monitoring tool" >HOMEPAGE="https://github.com/amanusk/s-tui" >SRC_URI="https://github.com/amanusk/s-tui/archive/v${PV}.tar.gz" Use a "SRC_URI arrow" here: https://github.com/amanusk/s-tui/archive/v${PV}.tar.gz -> ${P}.tar.gz For even more fun, reuse the HOMEPAGE while you're at it: ${HOMEPAGE}/archive/v${PV}.tar.gz -> ${P}.tar.gz > >LICENSE="GPL-2" >SLOT="0" >KEYWORDS="~amd64 ~x86" >IUSE="stress" What does this do? Gratuitously pull in yet another package? Why would you want to set this USE flag? Since you're not flagging to the build system whether app-benchmarks/stress should or should not be present during build time, this looks like you're trying to install another "suggested" package by taking the long way around of 1) changing a USE flag on one package, 2) calling emerge on that package and then 3) magically pulling in the other package, with additional build time you could have prevented by doing `emerge <other package>` to start of with. You can suggest accompanying packages in the <longdescription> in metadata.xml or perhaps in the ebuild through `elog` calls in pkg_postinst(). >RDEPEND=">=dev-lang/python-3 > dev-python/urwid > dev-python/psutil > dev-python/setuptools > stress? ( app-benchmarks/stress )" >DEPEND="${RDEPEND}" > >src_prepare() { > eapply_user > cd "${WORKDIR}/${PN}-${PR}" What is the PR doing there? Did you mean PV? If that path deviates from PV, it is common to set S=${WORKDIR}/... in global scope. Then you can replace the `eapply_user` and `cd` with a single call to `default` and then do: > rm Makefile And you may want to explain in a comment why that file should not be there. >src_install() { > python setup.py install --root="${D}" --optimize=1 We have a helper for that: distutils-r1.eclass . I've this package in my overlay [1]. Feel free to use it so I can delete from my overlay :) [1] https://github.com/fedeliallalinea/gallifrey/blob/master/app-admin/s-tui/s-tui-0.8.3.ebuild Thank you Jeroen for your explanations. That helps me to progress and correct my mistakes :-) Yes I removed the Makefile because the src_compile will execute make by default if a Makefile is found. However this Makefile is not useful : it creates docs for python or installs the package using pyinstaller (https://www.pyinstaller.org/). pyinstaller is not in the Gentoo repo and we can avoid this bug by skipping the src_compile and using python install. That's the best solution I found, tell me if you have a better idea. I read the distutils-r1.eclass doc, It's very usefull and I will use this eclass to handle the python dependencies and run the python command. Marco, I think your ebuild is not going to work because of the Makefile. ;-) Regards, agicquel (In reply to Antoine Gicquel from comment #3) > Marco, I think your ebuild is not going to work because of the Makefile. ;-) No makefile is called and the ebuild install fine. This happens because in distutils-r1.eclass EXPORT_FUNCTIONS [1] is defined then src_compile and src_install in fact call distutils-r1_src_compile and distutils-r1_src_install that they don't call the makefile. [1] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-10700010.3 Thank you for your explanation ;-) I had trouble with this Makefile and I did not know about the EXPORT_FUNCTIONS. However, s-tui uses Python3, should we change de PYTHON_COMPAT with python3_6 ? I think you also forget the dev-python/setuptools dependency. (In reply to Antoine Gicquel from comment #5) > Thank you for your explanation ;-) I had trouble with this Makefile and I > did not know about the EXPORT_FUNCTIONS. However, s-tui uses Python3, should > we change de PYTHON_COMPAT with python3_6 ? I think you also forget the > dev-python/setuptools dependency. You right, I changed my ebuild adding python3 support (package support also python2) and I corrected dependencies. I also migrate to EAPI=7 fixing in the correct way, I hope :), the RDEPEND, BDEPEND,... I'm going to maintain this in GURU now (it's been in there for a bit now). If you want to get it promoted to ::gentoo open a new bug but I'm not interested in being proxied for this one. |
