when packaging debian packages, dpkg-shlibdeps analyzes the linked
shared libraries of the binaries in given package by looking at their
names. but if the name does not include any useful versioning
information, it complains. we have no intention of versioning
libceph-common, as it is merely an internal shared library used by ceph
packages only. but there is no simple way to disable dpkg-shlibdeps'
warning of
dpkg-shlibdeps: warning: can't extract name and version from library
name 'libceph-common.so'
other than skipping the dpkg-shlibdeps for the whole package. so let's
just version it anyway.
Signed-off-by: Kefu Chai <kchai@redhat.com>
prior to this change, libcommon is a convenient library which gets
linked into librados, librbd and libcephfs and all ceph executables.
this incurs some problems:
- double dose of libcommon in memory space and HDD: waste of memory
and disk space.
- if an application links to two libraries including libcommon at the
same time. take librados and libcephfs as an example, they could
interfere with each other by changing the other guy's status.
after this change, libcommon is tuned into a shared library and
renamed to libceph-common. it will be installed into $prefix/lib/ceph,
and packaged in librados2.
ceph.spec.in,debian/librados2.install: package libceph-common in
librados2.
CMakeLists.txt:
- do not link against libboost-* if not necessary.
- s/common/ceph-common/g
- install libceph-common into $prefix/lib/ceph
- set rpath to $prefix/lib/ceph
- link against ceph-common if an executable needs access to non public
symbols in ceph.
Signed-off-by: Kefu Chai <kchai@redhat.com>
so the subvar of ${python:Depends} and ${python3:Depends} can be set
properly. also this silences the warnings like
warning: dpkg-gencontrol: Depends field of package python3-rgw:
unknown substitution variable ${python3:Depends}
Signed-off-by: Kefu Chai <kchai@redhat.com>
libcephd is a library that contains ceph daemon code
that can be statically linked in other applications.
Added MergeStaticLibraries.cmake that can merge static libraries
to form a bigger one. This approach avoids the need to mess with
STATIC libraries all over the code base.
Signed-off-by: Bassam Tabbara <bassam.tabbara@quantum.com>
With modern releases we should be able to make do with the call to
os_release_parse only which uses /etc/os-release which should be available on
most (all?) releases we currently support. this then allows us to remove the
runtime dependency which pulls in several other packages and would be nice to
avoid.
Fixes: http://tracker.ceph.com/issues/17425
Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
...at least, try to! This is a copy-paste of the ceph-mds
packaging with a search and replace mds to mgr.
Signed-off-by: John Spray <john.spray@redhat.com>
python3 is not a hard requirement to build ceph, so make it optional.
add an option named "WITH_PYTHON3" which accepts ON, OFF, or CHECK.
Fixes: http://tracker.ceph.com/issues/17103
Signed-off-by: Kefu Chai <kchai@redhat.com>
find_package(lttng-ust REQUIRED) fails to find the lttng library without
this change. because find_path(LTTNG_LIBRARY_DIR ...) does not search
in the default library paths. and the second mode of
FIND_PACKAGE_HANDLE_STANDARD_ARGS() does not stop the cmake with a fatal
message, even some of the required vars are missing. so use the
implemetantion from cmake upstream.
Signed-off-by: Kefu Chai <kchai@redhat.com>
New interfaces for fetching extended (and selective) stat information.
Additionally, applications can specify AT_NO_ATTR_SYNC in the flags to
indicate that they want to do a "lazy" statx that just hands out the
inode info from the cache, or AT_SYMLINK_NOFOLLOW to avoid following
symlinks when walking the path.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
DSA keys are being deprecated: http://www.openssh.com/legacy.html
drop.ceph.com will continue to allow the old DSA key but eventually,
users submitting logs using ceph-post-file will run into issues when
OpenSSH completely drops support for the algorithm.
Fixes: http://tracker.ceph.com/issues/14267
Signed-off-by: David Galloway <dgallowa@redhat.com>
and bump up the dependency of python version to 2.7.
py2.6 support was only necessary for older (now unsupported) distro
versions.
Signed-off-by: Kefu Chai <kchai@redhat.com>
since we are not using subvar of ${shlibs:Depends} in python3-* packages,
just exclude them in dh_shlibdeps.
this silences warnings like
```
warning: dpkg-gencontrol: package python3-cephfs: unused substitution
variable ${shlibs:Depends}
```
Signed-off-by: Kefu Chai <kchai@redhat.com>
so we can use subvars like ${python3:Depends} in debian/control.
this silences the warnings like:
```
warning: dpkg-gencontrol: Depends field of package python3-cephfs:
unknown substitution variable ${python3:Depends}
```
Signed-off-by: Kefu Chai <kchai@redhat.com>
Stop shipping /etc/init.d/rbdmap in the Debian packages. Ship the
rbdmap.service systemd unit file instead.
The corresponding change has already been made for RPMs, in
9224ac2ad2.
For Upstart-based systems (eg Ubuntu Trusty), the Debian packages
already contain rbdmap.conf.
(This gets us a tiny bit closer to being able to remove the rbdmap SysV
script from our tree entirely.)
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
* ceph-base: use ${python:Depends} instead of listing the python
dependencies manually, dh_python2 will scan the requirements
of ceph-detect-init. and fill the subst var for us.
* ceph-common: add ${python:Depends}, as it packages ceph,
and ceph-brag client.
* ceph-osd: it packages ceph-disk, so should add ${python:Depends}
as its dependencies.
dh_python2 will figure them out.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* debian/control:
as we have listed the linked libraries in Depends section, for example,
python-rados depends on librados. and we don't need `dpkg-shlibdeps` to
help figure out shared library substvar dependencies for us. by removing
them, we can silence the warnings of
```
warning: dpkg-shlibdeps: package could avoid a useless dependency if
debian/python-rados/usr/lib/python2.7/dist-packages/rados.x86_64-linux-gnu.so
was not linked against libpthread.so.0 (it uses none of the library's
symbols)
```
-lpthread is introduced by `python-config --ldflags` but it turns out we
are not using any symbols from pthread in the extension directly. and
pthread is included in glibc. so this does not added any extra
dependency to python-* pacakges. but it's desirable to have less
warnings.
* debian/rules: exclude python-* packages from dh_shlibdeps, as we will
not use it to prepare the shlib deps substvars for these packages any
more.
Signed-off-by: Kefu Chai <kchai@redhat.com>
