-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Bastian & Lazlo
On 15/09/13 12:03, Bastian Blank wrote: > On Sun, Sep 15, 2013 at 12:30:22PM +0200, László Böszörményi (GCS) > wrote: >> On Sun, Sep 15, 2013 at 12:00 PM, Bastian Blank >> <wa...@debian.org> wrote: >>> However there are several problems left: - ceph-common depends >>> on python-flask and python-ceph. >> Why this is a problem? What I see is that python-flask should be >> moved to python-ceph . > There is a python script ceph-rest-api. Where is this used? Why > does it warrant a dependency on 20 other packages? Dumpling (0.67.x) is the first release with basic support for a REST api for administering a ceph cluster - this binary supports this feature - but more of a demo of how to use than anything really usable (dev mode only). However I do agree that it looks like it should be in ceph. >>> - ceph-common is not _arch-all_, why does it exist? >> Tools that used by other packages that can be installed >> independently. Should it be named like ceph-base or ceph-tools? > > Not sure right now. It looks like a random dash of tools, stashed > together without much thinking. - ceph, rados, rbd: Tools to manage > different parts of ceph, remotely. - ceph-authtool: Works on > keyring files, so needs to run locally on the monitor. - > ceph-rest-api: Where does this belong to? - ceph-dencoder, > ceph-syn: This are test or debugging tools. > > I would - move ceph-authotool and maybe ceph-rest-api into ceph, - > move cephfs and mount.ceph into ceph-common - move ceph-dencoder > and ceph-syn into ceph-test, - move stuff from ceph-resource-agents > into ceph and - drop ceph-fs-common and ceph-resource-agents. > >>> - Why ceph-mds? >> Ceph has three independent blocks. Metadata servers (-mds) are >> one of them. Please see the overview[1]. > > Yeah. But why does it need a different package? What does this > extra package bring for the user? For context, the ceph-mds function was split out in the packaging as MDS is not as well tested/production grade as the RADOS and RBD features; In Ubuntu we use this to signal which parts receive full support from the Ubuntu Server and Security teams. I appreciate that this is not required for Debian but its also in the upstream packaging so it would be nice if these splits could stay (see notes below about why keeping packaging consistent across upstream, Debian and Ubuntu is a good idea). >>> - ceph depends on fdisk, parted and whole lot other crap it >>> does not need. >> Agree on this. Don't know how it made there. > > Because ceph-disk (another incompletely documented indirection) > uses it. The important parts (ceph-mon, ceph-osd) works fine > without it. ceph-disk is a key part of the deployment infrastructure for ceph so these are important dependencies for anyone deploying ceph at scale using upstream Chef recipes or ceph-deploy. >>> - A lot of Replaces. >> There were package renames, users may have packages from upstream >> or Ubuntu. That's make it complex. > > Not a concern for Debian. It was never in a stable release. I think it is a concern for Debian; the principle source of Ceph packages for Debian to-date has been from upstream, so ensuring smooth transitions to/from Debian/upstream is important IMHO. >>> - python-ceph needs stricter dependencies. >> Will check. > > At least the dependencies for librados2 and librdb1 needs to be > stricter. The dependency on libcephfs1 is missing. Agreed - python-ceph only just grew bindings for cephfs so that's just an oversight. Good spot. >= on equiv binary package version should do the job for the librbd/rados depends. Laszlo - re -java/-jni split - this is in compliance with the Java packaging policy: http://www.debian.org/doc/packaging-manuals/java-policy/x114.html I really think we need to stick with the packaging structure and naming that is already in place as much as possible; All of the existing deployment tooling (chef, juju, ceph-deploy) is written based on this structure on Debian based systems; diverging is just going to create work in other areas and potentially alienate the Debian packaging as its different to the packaging that the Ceph community has been using for the last two years... at least! FYI once ceph is up-to-date in Debian I'm intending on landing ceph-deploy as a way of deploying ceph on Debian - it makes testing much easier. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJSNe0LAAoJEL/srsug59jDGLEP/3KDiq6fbzcNUeaw0JuCSK0F QNfMdAQWRa86UX8zOJvtlhjbRJlwPWY4kRj52fxsXZTOcs+9t+ooTZ0ACwYTy0K3 jPscTwoev1rBvbYD1kJXCrd8OVg9I1WC0cK30OiPQ7y6SrTf+84fpHWHAZhcoQa7 TD5j+stSk0Nfko8Wj6K3xEy1J7PgoY16gcAbozEW/35zAz7tFUjhRgwJSJ9tBCdR 2H7rn2Dmxdk5RPNutKM1pKFiOdCTYOz87+ptYYdeKbvRuxU9b+dl2wb5U9D5IfTH mBJm4dcQQr0IDxMdhG7VJxb/wSA8Nog5fxIxelloPg7wI65D4Lf/m0QvYXEpRc56 N5xCWaLKw5aTmh4Cviz7k6SvnXNfWoemF7LueETJFo1IUFS2jBB2tbYOcXFpzvhX IrZN745JEIkSQ7071LpLYfB0/WyPr7Kcwgwx+4fr/Lo1tWKmm37fARic6TAJGkg7 V2K2pXH5kDWdTjnQ9//0NNVzAVUU9+JLiG0qWcXYCqmpAts8xnUvuG0CAAcQogmq EP3QAm3f1u9w4jc5uRnRTFX38xuKnPZz3X6so8HCvB3jPjmiPZYZzhhR4OwqaXCz wcQMRLyP+6lg3sV5teRaHhgnuzUXtGOV4870G9z0oycJavHANNGAPoHm3S8OJmd6 ImJkC6cOr0XQ4flnmaJp =Jxi7 -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
