On 8-8-2017 08:59, Fabian Grünbichler wrote: > On Mon, Aug 07, 2017 at 05:30:06PM +0200, Willem Jan Withagen wrote: >> On 7-8-2017 16:58, Ken Dreyer wrote: >>> On Wed, Aug 2, 2017 at 7:39 AM, Alfredo Deza <adeza@xxxxxxxxxx> wrote: >>>> The ceph-debuginfo package has continued to increase in size on almost >>>> every release, reaching 1.5GB for the latest luminous RC (12.1.2). >>>> >>>> To contrast that, the latest ceph-debuginfo in Hammer was about 0.73GB. >>>> >>>> Having packages that large is problematic on a few fronts: >>> >>> I agree Alfredo. Here's a similar issue I am experiencing with the source sizes: >>> >>> Jewel sizes: >>> 14M ceph-10.2.7.tar.gz >>> 82M ceph-10.2.7 uncompressed >>> >>> Luminous sizes: >>> 142M ceph-12.1.2.tar.gz >>> 709M ceph-12.1.2 uncompressed >> >> I'm on that same page. >> > > +1 (Proxmox VE, also building downstream packages) > > Boost seems to be by far the biggest culprit - we initially built our > packages using the system boost option to save some space, but this > broke one time too often and we are now also shuffling tons of data > around for every version bump. I have not (yet) run into that problem. Perhaps because the package-maintainer for FreeBSD does a good job. Next question would be the install location for libboost stuff. Because it needs to be out of the way for the regular boost stuff. But then linking any Ceph code would again require extra TLC to start using the correct libs. Until now I did not really think of it, but rocksdb is statically linked and that is the reason why it does not cause this kind to challenge. But static linking only bloats codesize even more. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
