Вход:  Пароль:  
FreeSource: VitalyLipatov/gecko ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

О появлении libgecko в дистрибутиве


Оглавление документа


Не думаю, что я забегаю вперёд паровоза, поскольку не вижу такового. А если и так, то паровоз всё же архаичный вид транспорта, а ALT Linux Team- передовая группа разработчиков.
Предлагается выделить движок Gecko в отдельный пакет libgecko, как это требуется общепринятым подходом к сборке пакетов.
Текущий вариант нарушает несколько правил:

Это позволит формировать ясные зависимости в таких пакетах как


Файлы из Gecko SDK разместить в libgecko-devel


Вот список библиотек gecko:


Mikhail Zabaluev:

> Некоторые проекты, например, последний релиз SWT, требуют для
> сборки Gecko SDK. Это усеченный набор заголовочных файлов и
> библиотек из Mozilla, представляющий стабильные API. Однако в
> Gecko SDK в том виде, как он распространяется с сайта, есть
> несколько статических архивов, отсутствующих в mozilla-devel:
> libembed_base_s.a
> libxpcomglue.a
> libxpcomglue_s.a
>
> Можно ли их получить в составе mozilla-devel или выделить
> вместе с другими необходимыми файлами в отдельный пакет gecko-sdk?

И заодно подумать о libgecko, чтобы вернуться наконец на unix way и покончить со безобразием, которое выглядит например так:
$ locate libxpcom.so
/opt/openoffice.org1.9.90/program/libxpcom.so
/usr/lib/OpenOffice.org1.1.4/program/libxpcom.so
/usr/lib/firefox-1.0.1/libxpcom.so
/usr/lib/libxpcom.so
/usr/lib/mozilla/libxpcom.so
/usr/lib/nvu-0.90/libxpcom.so
/usr/lib/thunderbird-1.0/libxpcom.so


или так:
$ apt-cache whatdepends libgtkembedmoz.so

yelp-2.9.3-alt1
python-module-pygnome-gtkmozembed-2.10.0-alt2
liferea-mozilla-0.9.0b-alt1
libdevhelp-0.9.3-alt1.1
galeon-1.3.20-alt1
epiphany-extensions-1.6.1-alt1
epiphany-1.6.1-alt1


Думаю, не стоит забегать впереди паровоза: раз уж все эти проекты предоставляют свою версию libxpcom и пр., у них на это могут быть свои причины (как избежать хаоса в auto dependencies, это другой вопрос). Другое дело Gecko SDK: эта штука (особенно glue) нужна многим проектам, и является официальным средством для разработки стабильных расширений/встраиваний. Приложения, содержащие Gecko, могут при этом выступать как взаимозаменяемые поставщики Gecko API.

Немного противоречиво – если приложения, содержание Gecko, могут быть поставщиками Gecko API, следовательно, библиотеки Gecko в них имеют одинаковую функциональность, и дублировать их смысла нет.


On Sunday 17 April 2005 19:52, Michael Shigorin wrote:

> Кажется, эту тему обсуждали — когда выносили плагины.
> Вывод был таким IIRC: версии разные, это почитай что Direct X?
> hell.

Я догадываюсь что это hell, но всё же надеюсь что раз это штука имеет API, то разработчики имеют некоторую порядочность в обращении с ним и преемственность наблюдается. Если же в каждом из перечисленных проектов (Open Office?.org, mozilla, firefox, thunderbird, а также Sunbird, который у нас ещё не собран) используется свой собственный Gecko с никому не понятными правками, то печально всё это. Говорим о стандартах и не соблюдаем их...


В общем, был я в этом аду. Никакого hell там нет. Всё красиво – Mozilla, Firefox, Thunderbird, NVU, OOo 1.1.4, OOo 2.0 отлично живут с одними и теми же библиотеками (я из Thunderbird взял). Экономия небольшая – мегабайт 15, но зато как удобно критичные баги исправлять. Одновременно и без перевыкачивания трёх сотен метров.


Konstantin A. Lepikhov:
Все ждем стабильного XULRunner. После этого радостного события празднуем месяц, потом выкидываем mozappsuite, монолитные FF/TB/NVU/SB, ставим XR + его xul клиентов и вот _тогда_ делаем libgecko и sdk.

Конкретные возражения

Ссылки


Ссылок на эту страницу нет


 
Файлы [Скрыть файлы/форму]
Один комментарий. [Показать комментарии/форму]