В Fedora принята довольно строгая политика по отношению к библиотекам - если приложение требует какую-либо библиотеку, то оно должно использовать ту копию, которая присутствует в репозитории, а не ту, что разработчик приложения запихнул в tarball. Чтоб добиться этого, мэйнтейнер, проводящий аудит пакета (Review), обычно требует физически удалить библиотеки, дублирующие системные, из распакованных исходных текстов на этапе сборки RPM-пакета (обычно на стадии %prep). Исключения из этого правила возможны лишь с разрешения FESCo. Если-же приложение при сборке использует bundled libs, то значит кто-то недоглядел, и стоит открыть заявку в багзилле.

Некоторые потенциальные участники Fedora, а также некоторые разработчики постоянно критикуют это требование, за излишнюю (и, порой, кажущуюся искусственно созданной) сложность. Мол "в простом в настройке и использовании дистрибутиве Xxx и Yyy такого нет, и живут ведь как-то". Опять-же, в среде Java-программистов, сформирована привычка таскать все библиотеки с собой, что особенно актуально для "больших" приложений, которые пользователи скачивают со сторонних сайтов (например, NetBeans только начал свое возвращение в Fedora, и его пользователи просто вынуждены его качать откуда-то еще). Эта практика возникла не на пустом месте. Иногда разработчики вынуждены учитывать бедность репозиториев других Unix-систем (того же Mac OS X), не говоря уже об известной не-Unix проприетарной системе, где просто ничего нет из коробки. Порой разработчики застряли со старым API какой-то из библиотек и везде ее таскают за собой. Иногда-то наоборот, в репозиториях лежат слишком старые версии, а разработчики использовали какие-то новинки последних версий. Но, к сожалению, порой они включают библиотеки по привычке, просто так.

Fedora требует исключать так называемые bundled libs по нескольким причинам - мы тем самым помогаем разработчикам, проверяя работу с последними версиями библиотек, уменьшаем время сборки и размер итогового пакета, гарантируем, что исправления ошибок и дыр в безопасности сразу появятся во всех приложениях, ну и в целом создаем приятное эстетическое впечатление от системы. К сожалению, как и было уже сказано, некоторые потенциальные мэйнтейнеры ругают эту практику, кивая на маргинальные дистрибутивы, где такого правила нет. Что до аргументов о безопасности и исправлении ошибок, то они либо игнорируются, либо на них с гордо вскинутой головой отвечается, что "это не помешает нам исправлять ошибки - если что, то просто пересоберем с патчами". Ну что ж, эта самоуверенность принесла свои плоды. Давний участник Fedora, специалист по безопасности, работающий на НАТО и ЦРУ, математик, специализирующийся на формальных методах (к сожалению, подавляющая часть его работ засекречена его работодателями) и участник соответствующей Fedora Formal Methods SIG, David A. Wheeler указывает на недавний отчет от компании Aspect Security (к сожалению, он registerwalled). В отчете сообщается, что примерно 26% Java-приложений, скачанных из "основных" репозиторев, то есть именно тех, которые традиционно поставляются сразу со всеми нужными для запуска библиотеками, имеют уже известные проблемы с безопасностью. Качайте и дальше большие Java-приложения в формате ZIP, но только потом не жалуйтесь на "дырявый линукс" и не кусайте локти, что отключили SELinux, который "не нужен на десктопе" и "только мешает". Особенно эта новость актуальна всвязи с недавними сообщениями о серьезных проблемах (за февраль и за апрель) с безопасностью Java.

Немного отвлекшись сообщим, что ситуация с Java в Fedora именно потому и не очень хороша, что участники Fedora Java SIG двигаются очень медленно, тратя время на расплетение клубка bundled libraries, которые наворотили вокруг своих приложений Java-разработчики.

Итак, возвращаясь к теме - David в комментарии в своем блоге подчеркивает, что проблема приобрела такое широкое распространение из-за единственной причины - Java разработчики не выучили урока, давно усвоенного подавляющим количеством программистов на C/C++ (увы, еще не всеми) - всегда надо использовать системные версии библиотек. Он подчеркивает, что он и многие другие специалисты по безопасности уже не раз возвращались к теме bundled libs, и что приложение с кучей упакованных библиотек можно лишь расценивать, как преступную халатность и общую неряшливость команды разработки. Таская библиотеки со своим приложением, разработчик сознательно отказывается от главного преимущества OpenSource - от аудита коммьюнити. Это очень и очень трудно оправдать.

Вот почему в ведущих дистрибутивах Linux, таких как Fedora, Debian, openSUSE, тратят время на такую странную задачу - выкусывать библиотеки из tarball и собирать с уже имеющимися. Так было, есть и будет - и ныне, и присно, и во веки веков.