diff options
| -rw-r--r-- | .gitignore | 1 | ||||
| -rw-r--r-- | python-libaio.spec | 120 | ||||
| -rw-r--r-- | sources | 1 |
3 files changed, 122 insertions, 0 deletions
@@ -0,0 +1 @@ +/libaio-0.9.1.tar.gz diff --git a/python-libaio.spec b/python-libaio.spec new file mode 100644 index 0000000..6ba4530 --- /dev/null +++ b/python-libaio.spec @@ -0,0 +1,120 @@ +%global _empty_manifest_terminate_build 0 +Name: python-libaio +Version: 0.9.1 +Release: 1 +Summary: Linux AIO API wrapper +License: LGPLv3+ +URL: http://github.com/vpelletier/python-libaio +Source0: https://mirrors.nju.edu.cn/pypi/web/packages/ea/94/4d5466535240f2c8132b1f867bcb62047ecbf31cf2fedeb5592aa9f81969/libaio-0.9.1.tar.gz +BuildArch: noarch + + +%description +When sending or expecting data, the typical issue a developer faces is knowing +when the operation will complete, so the program can carry on. +- read/write/recv/send: blocks until stuff happened +- same, on a non-blocking file descriptor: errors out instead of blocking, + developper has to implement retry somehow, and may end up wasting CPU time + just resubmitting the same operation over and over. +- select/poll/epoll: kernel tells the program when (re)submitting an operation + should not block (if developer is careful to not have competing IO sources) +AIO is the next level: the application expresses the intention that some IO +operation happens when the file descriptor accepts it *and* provides +corresponding buffer to the kernel. +Compared to select/poll/epoll, this avoids one round-trip to userland when the +operation becomes possible: +- kernel sends notification (ex: fd is readable) +- program initiates actual IO (ex: read from fd) +Instead, kernel only has to notify userland the operation is already completed, +and application may either process received data, or submit more data to send. + +%package -n python3-libaio +Summary: Linux AIO API wrapper +Provides: python-libaio +BuildRequires: python3-devel +BuildRequires: python3-setuptools +BuildRequires: python3-pip +%description -n python3-libaio +When sending or expecting data, the typical issue a developer faces is knowing +when the operation will complete, so the program can carry on. +- read/write/recv/send: blocks until stuff happened +- same, on a non-blocking file descriptor: errors out instead of blocking, + developper has to implement retry somehow, and may end up wasting CPU time + just resubmitting the same operation over and over. +- select/poll/epoll: kernel tells the program when (re)submitting an operation + should not block (if developer is careful to not have competing IO sources) +AIO is the next level: the application expresses the intention that some IO +operation happens when the file descriptor accepts it *and* provides +corresponding buffer to the kernel. +Compared to select/poll/epoll, this avoids one round-trip to userland when the +operation becomes possible: +- kernel sends notification (ex: fd is readable) +- program initiates actual IO (ex: read from fd) +Instead, kernel only has to notify userland the operation is already completed, +and application may either process received data, or submit more data to send. + +%package help +Summary: Development documents and examples for libaio +Provides: python3-libaio-doc +%description help +When sending or expecting data, the typical issue a developer faces is knowing +when the operation will complete, so the program can carry on. +- read/write/recv/send: blocks until stuff happened +- same, on a non-blocking file descriptor: errors out instead of blocking, + developper has to implement retry somehow, and may end up wasting CPU time + just resubmitting the same operation over and over. +- select/poll/epoll: kernel tells the program when (re)submitting an operation + should not block (if developer is careful to not have competing IO sources) +AIO is the next level: the application expresses the intention that some IO +operation happens when the file descriptor accepts it *and* provides +corresponding buffer to the kernel. +Compared to select/poll/epoll, this avoids one round-trip to userland when the +operation becomes possible: +- kernel sends notification (ex: fd is readable) +- program initiates actual IO (ex: read from fd) +Instead, kernel only has to notify userland the operation is already completed, +and application may either process received data, or submit more data to send. + +%prep +%autosetup -n libaio-0.9.1 + +%build +%py3_build + +%install +%py3_install +install -d -m755 %{buildroot}/%{_pkgdocdir} +if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi +if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi +if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi +if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi +pushd %{buildroot} +if [ -d usr/lib ]; then + find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/lib64 ]; then + find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/bin ]; then + find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst +fi +if [ -d usr/sbin ]; then + find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst +fi +touch doclist.lst +if [ -d usr/share/man ]; then + find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst +fi +popd +mv %{buildroot}/filelist.lst . +mv %{buildroot}/doclist.lst . + +%files -n python3-libaio -f filelist.lst +%dir %{python3_sitelib}/* + +%files help -f doclist.lst +%{_docdir}/* + +%changelog +* Wed May 17 2023 Python_Bot <Python_Bot@openeuler.org> - 0.9.1-1 +- Package Spec generated @@ -0,0 +1 @@ +d366b423ac8dcbe30e2d1bb01f4c38e2 libaio-0.9.1.tar.gz |