XRootD software framework
XRootD software framework is a fully generic suite for fast, low latency and scalable data access, which can serve natively any kind of data, organized as a hierarchical filesystem-like namespace, based on the concept of directory. As a general rule, particular emphasis has been put in the quality of the core software parts.
- Devel package for openSUSE:Factory
-
4
derived packages
- Links to openSUSE:Factory / xrootd
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout science/xrootd && cd $_ - Create Badge
Refresh
Refresh
Source Files (show unmerged sources)
| Filename | Size | Changed |
|---|---|---|
| _multibuild | 0000000055 55 Bytes | |
| harden_cmsd@.service.patch | 0000000851 851 Bytes | |
| harden_frm_purged@.service.patch | 0000000887 887 Bytes | |
| harden_frm_xfrd@.service.patch | 0000000875 875 Bytes | |
| harden_xrootd@.service.patch | 0000000863 863 Bytes | |
| xrootd-5.6.9.tar.gz | 0006701277 6.39 MB | |
| xrootd-rpmlintrc | 0000000264 264 Bytes | |
| xrootd-user.conf | 0000000138 138 Bytes | |
| xrootd.changes | 0000041068 40.1 KB | |
| xrootd.spec | 0000018802 18.4 KB |
Comments 2
Just a small heads up, regarding generating/packaging the Python bindings:
https://github.com/amadio/xrootd/commit/39585c3274b8569cd98a8239e3db18db728ea1ce
This should allow to build the bindings in a separate package, or maybe a multibuild. This also allows to reduce the number of rebuilds, as e.g. any changes in the non-default python version will no longer cause any rebuilds of the main package.
Many thanks Stefan, will add that commit to the version 5.5.5 update I am in the process of packaging and see how it goes.