Bug 6851

Summary: Убрать файлы из /usr/lib
Product: Sisyphus Reporter: Vitaly Lipatov <lav>
Component: mozillaAssignee: Alexey Gladkov <legion>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: normal    
Priority: P2 CC: eostapets, lakostis
Version: unstable   
Hardware: all   
OS: Linux   

Description Vitaly Lipatov 2005-05-16 02:02:54 MSD
Хотелось бы убрать ссылки из /usr/lib, чтобы mozilla сидела 
у себя в HOME и не мешала другим пакетам устанавливаться (я про libgecko). 
Если этому что-то мешает, хотелось бы ознакомиться с соображениями. 
Если есть подозрение, что что-то сломается - я постараюсь их проверить.
Comment 1 Eugene Ostapets 2005-09-02 17:26:39 MSD
А в чем собственно проблема с libgecko? На чем именно конфликт?
Comment 2 Vitaly Lipatov 2005-09-03 00:10:56 MSD
Ну собственно уже не в чём, после того как идея libgecko не нашла поддержки. 
Я успешно эксплуатировал вариант, когда общие для проектов mozilla, firefox, 
sunbird, nvu, thunderbird библиотеки входили в libgecko, и не таскали каждый 
свою. 
Никому не надо - ладно, я мегабайты не экономлю. 
Comment 3 Eugene Ostapets 2005-09-03 00:34:01 MSD
Я готов поучаствовать в эконмике...
Экономика должна быть экономна...:)
Comment 4 Vitaly Lipatov 2005-09-03 01:18:50 MSD
Я пытался - сделал libgecko, куда вошли все эти библиотеки. Чтобы это жило в 
системе, mozilla не должна класть ссылки в /usr/lib. Чтобы была экономия, из 
каталогов всей указанной семейки нужно удалить файлы, которые уже есть в 
libgecko. 
Но есть и аргументы против: 
"Этому пакету пока не место в Сизифе - он сыр по идейным параметрам :) 
libgecko и прочие libxx из seamonkey будут собраны и востребованы лишь только 
когда этого захотят сами разработчики seamonkey. В ближайшем будущем этого не 
предвидится. Поэтому я и прошу убрать этот пакет - пусть он лежит где-нибудь в 
сторонке (например в Дедале). 
--  
WBR, Konstantin Lepikhov 
Comment 5 Konstantin A Lepikhov (L.A. Kostis) 2005-09-03 01:33:30 MSD
Для меня этот пакет (libgecko) не имеет смысла - т.к. сейчас в Сизифе уже есть
xulrunner, который и так провайдит все эти библиотеки вместо libgecko (и это
более правильно логически) + я готовлю rpm с nss/libnspr, которая будет
провайдить все остальные ssl/pki библиотеки. Для старой mozilla-suite надо
действительно профиксить rpath (если его уже не пофиксили), чтобы она лазила за
своими либами в /usr/lib/mozilla, т.к. они уже скоро будут несовместимы ни с
tb/fx, ни с seamonkey. Т.е. правильная связка такова:
xulrunner - gecko runtime + xul runtime
nss - ssl/crypto/pki
nspr - libnspr
и текущему мантейнеру suite надо уже смотреть на seamonkey и притирать его к
"правильной связке".
Comment 6 Vitaly Lipatov 2005-09-03 02:14:46 MSD
Во :) 
Повторил просьбу в incoming@ удалить libgecko 
Comment 7 Alexey Gladkov 2005-09-04 16:10:30 MSD
Сейчас firefox, thunderbird & co переходят на единую платформу - xulrunner.
Соответственно через некоторое время он переедит в /usr/lib . Как я понимаю,
seamonkey - это единственное gecko-based приложение, не идущее по этому пути.
Поэтому очень не хочется, чтобы в будуйщем возникли конфликты между mozilla и
xulrunner. 

Я присоединяюсь к просьбе Константина и тоже прошу убрать библиотеки из /usr/lib.
Comment 8 Vitaly Lipatov 2005-09-04 17:27:51 MSD
(In reply to comment #7) 
> Я присоединяюсь к просьбе Константина и тоже прошу убрать библиотеки 
из /usr/lib. 
Вообще-то багу вешал я и речь шла о библиотеках из mozilla, кладомых 
в /usr/lib :) 
И вообще, так как последнее время mozilla пакетит Константин, то я вообще не 
понимаю, может ли он просить сам себя :) 
 
 
Comment 9 Eugene Ostapets 2005-09-04 17:42:49 MSD
Я стал следующим бойцом с этим творением:) Так что просят меня... :)
Comment 10 Eugene Ostapets 2005-09-28 17:59:02 MSD
Едет 1.7.12 - там убрано /usr/lib/*.so.
В предверии появления SeaMonkey меня интересует судьбы
/usr/include/{nspr,nss}, где обещанные пакеты, дабы убрать конфликт между двумя
версиями мозилы...
Comment 11 Alexey Gladkov 2005-10-17 06:33:46 MSD
17.10.05 идет nspr собираемый из cvs (в нем сейчас 4.7.0).
На счет nss сейчас думаю.
Comment 12 Eugene Ostapets 2005-10-17 10:48:36 MSD
Хм... Пока что продукты mozilla используют 4.5.1, и еще две недели назад я
подготовил 4.6(актуальную на тот момент), но из-за давки с OOo 2.0 заливать не
стал... Ну так кто возьмет на себя libnspr, я или вы?
Comment 13 Alexey Gladkov 2005-10-17 11:54:47 MSD
(In reply to comment #12)
> Хм... Пока что продукты mozilla используют 4.5.1, и еще две недели назад я
> подготовил 4.6(актуальную на тот момент), но из-за давки с OOo 2.0 заливать не
> стал... Ну так кто возьмет на себя libnspr, я или вы?

У меня уже все готово. 
Я хочу на nspr завязать еще и xulrunner ... a ему нужен самый свежий. Если вы не
против, то я его возьму. 
Comment 14 Eugene Ostapets 2005-10-17 13:34:53 MSD
Я не против. Самое главное чтобы mozilla-suite & seamonkey сработались с новой
версией, а то at@ со своим поиском дублирующихся символов заспамит... :)
Comment 15 Alexey Gladkov 2005-10-17 14:43:39 MSD
(In reply to comment #14)
> Я не против. Самое главное чтобы mozilla-suite & seamonkey сработались с новой
> версией, а то at@ со своим поиском дублирующихся символов заспамит... :)

Не вижу причин чтобы mozilla c ним не собралась. Только вам придется приложить
один патч для этого :)
В firefox я наткнулся на то, что она не может собраться с внешним nspr . Для
сборки с ней нужен патч. Причем падает она в nss. Как только я оторву nspr
положу патч.
Если вам это удастся раньше буду рад воспользоваться вашими трудами.

Для этих писем есть мощный инструмент - /dev/null. Оттуда еще никто не созвращался.
Comment 16 Eugene Ostapets 2005-10-17 14:54:42 MSD
С mozilla-suite патчей нужно намного больше... Я как раз занимаюсь убеждением
сборочной среды в необходимости таки собраться с внешним libnspr... А затем и
libnss :)