SliTaz Forum
You are not logged in.
Кто-нибудь имеет положительный опыт установки в slitaz сторонних пакетов (разумеется через convert)?
Репозиторий у slitaz большой, но есть привычки и предпочтения.
Например мне не хватает дебиановских gedit и gnome-commander (mc в slitaz по умолчанию уж очень убогий).
То есть насколько convert реально работающий инструмент?
Об отсутствующих зависимостях я не говорю, их можно посмотреть и доустановить.
Работают ли программы установленные из нескольких сконвертированных пакетов deb или rpm ?
Если ссылки на другие системы не являются здесь offtop, то интерсное решение нашего соотечественника можно увидеть http://uco.puppyrus.org/forum/thread176.html
Называется SFSLinux. Самоделка.
Концепции разработки перекликаются с принципами slitaz, а база Паппи-линукс.
Точнее так: не Паппи-линукс, а любые пакеты в формате sfs.
Этому парню удалось собрать систему, работающую прежде всего с sfs-пакетами, а также со сторонними deb-пакетами.
Offline
Тут как в анекдоте: 50/50 (либо установится, либо не установится)
Те *.deb, что конвертил - в основном установились нормально.
Проблемы были с теми, где требуемые версии зависимостей отличны от тех, что в системе.
Offline
А создание собственных пакетов сложно?
Сам я не умею их делать. Как-то пожаловался, что [c]mc[/c] не поддерживает мышки, так mojo сделал новый пакет с поддержкой мышки. 
Offline
Создавать собственные пакеты в SliTaz не слишком сложно. Имеющаяся система Cookutils несколько облегчает этот процесс по сравнению с тем, как если бы это делалось руками. Но принцип тот же.
Надо знать откуда взять исходники. Указываем адрес в рецепте, кук скачает исходники (или в следующий раз возьмет их из кеша) и распакует.
Надо знать зависимости сборки пакета и зависимости работы пакета. Указываем в реепте, кук скачает их (и зависимости зависимостей тоже) и установит их в чистую чрут-систему, а после компиляции удалит их из чрут-окружения.
Надо знать параметры, с которыми конфигурируются исходники перед компиляцией. Записываем в рецепт. Дальше обычная компиляция (мейк) и установка (мейк инстал) в отдельную папочку вместо корня файловой системы.
Дальше забираем из этой папочки только нужные нам файлы, оставляя всякие ненужные маны, доки и ченжлоги. При желании можно создать еще один пакет и оставить там только эти маны и доки.
После этого кук минифицирует бинарники и собирает пакет. Если что-то нас не устраивает или если возникают ошибки, меняем рецепт и запускаем новую итерацию, до победы. Хорошим подспорьем являются уже имеющиеся рецепты. Так, на основе рецептов murrine и murrine-themes я на днях сделал рецепты для equinox и equinox-themes. Хотя сам только недавно начал разбираться в этой кухне и за свою жизнь скомпилировал едва ли с десяток программ.
Offline
Спасибо Aleksej, наверное Ваш ответ самый правильный для slitaz с учетом его отличий от debian-linux.
Но все же хотелось бы иметь возможность устанавливать deb- rpm- пакеты с их зависимостями также просто, как например в Debian или Ubuntu (разврат налицо).
Я уже привык в Ubuntu (и других линуксах) к редактору gedit и файл-менеджеру gnome-commander.
Все это дело вкуса и привычки, но в данном случае повод проверить возможности системы (и свои).
Скачал и сконвертил deb-пакеты, получил 34 пакета: от alsa-lib-1.0.26.tazpkg до popt-1.16.tazpkg
Установил их и появилась иконка gnome-commander в меню-->утилиты.
Но сам gnome-commander не запускается ни из меню ни из терминала.
Я не стал компилить gnome-commander из исходников - ясно, что не будет всех зависимостей.
Я попробовал и установил в persistent slitaz (на отдельном разделе винчестера) пакет debian aptitude.
Он установился, но не до конца сконфигурировался - различия ОС. Надо править руками.
Этим пакетом попробовал поставить (эксперимент) достаточно тяжелые по зависимостям gedit и gnome-commander.
gedit - 294 новых пакетов, скачать 136 MБ архивов.
gnome-commander - 261 новых пакетов, скачать 118 MБ архивов.
gnome-commander встал, но не запускается - не хватает libexiv2-->libpcre.so.1
Нашел пакет pcre-8.31-6.ram1.i386.rpm (только в нем нашел именно libpcre.so.1), сконвертировал и установил этот pcre
После этого libpcre.so.1 появился в /lib/
Переустановил gnome-commander но получил сообщение об ошибке:
Error: Не удалось выполнить оперативную настройку 'libc6'. Подробней, смотрите в man 5 apt.conf о APT::Immediate-Configure. (2)
Дело в том, что при установке gnome-commander есть сообщение:
Будут установлены следующие дополнительные пакеты:
libc6 libc6-i686 libexiv2-9 libexpat1 libgcc1 libstdc++6 zlib1g
А потом:
/usr/bin/dpkg: unrecognized option '--status-fd'
Command line: /usr/bin/dpkg --status-fd 15 --unpack --auto-deconfigure /var/cache/apt/archives/libgcc1_1%3a4.4.5-8_i386.deb /var/cache/apt/archives/libc6_2.11.3-4_i386.deb
BusyBox v1.18.4 (2012-03-14 03:32:25 CET) multi-call binary.
Попытка установить эти 7 пакетов через: dpkg -i xxxx..deb
приводит к зацикливанию зависимостей между ними на libc6
gedit устанавливался, но в результате "улетел в пространство" - следов нет.
Все это я изложил потому, что:
1. в репозитории slitaz много чего нет - и это нормально и понятно,
2. в репозиториях debian/ubuntu много чего есть - и это тоже нормально и понятно,
3. наличие в slitaz конвертера из deb и rpm пакетов указывает на их совместимость со slitaz
4. надо искать пути беспроблемной установки сторонних (для slitaz) программ с многочисленными зависимостями
5. от решения этого вопроса выиграют не только пользователи, но и разработчики,
6. потому что многие другие маленькие и средненькие линуксы "замкнуты" на свои небогатые репозитории.
Ха! Я все сказал. (из одного старого кино про индейцев).
Offline
Здравствуй, sklimkin!
Спасибо за бесценный опыт. Теперь, если кто-то станет говорить про использование пакетов из чужих репозиториев, я буду просто давать им эту ссылку: http://forum.slitaz.org/topic/использование-deb-и-rpm-пакетов-в-slitaz#post-17319 Ага, этим жупелом можно пугать новичков и отмахиваться от их назойливых требований "сделать всё как в должно быть (т.е в убунте)" 
Я считаю, что дистрибутивов, использующих дебиановские репозитории и без нас достаточно; дебиан, разные *убунты, минты*, один из паппи(рус)... Выбор большой.
К слову, убунту не только использует готовые пакеты, но и часто вносит в них собственные патчи, так в названии пакета появляется слово "убунту". А вот, паппирус, кажется, всеяден. В одном и том же дистрибутиве могут находиться как пакеты, специально для него откомпилированные, так и разные другие части-запчасти, взятые (уже и не помню, откуда) из разных других репозиториев. А разве в папирусе всё безоблачно с использованием чужих пакетов? Как насчет повторить тот же опыт, но в папирусе? Почему-то мне кажется, что результат будет похожим.
Тут нужно понимать, для чего слитаз создавался. Это не просто "еще один (дистрибутив) линукс(а)". Он является последователем (идеологии) LFS (Linux From Scratch). Все пакеты собираются из исходников. Для этого есть специальные средства, облегчающие процесс. В большинстве случаев, для сборки пакета достаточно одного рецепта, в котором описано многое, сайт программы, откуда брать исходники, с какими параметрами его компилировать, какие из скомпилированных файлов положить в пакет, какие программы нужны для работы пакета, и какие нужны для сборки, какие действия нужно выполнить после установки пакета, и какие после удаления пакета, какие из файлов пакета являются конфигурационными (чтобы при обновлении пакета не затёрлись ваши предыдущие конфиги). А для того, чтобы собрать новую версию программы, зачастую достаточно только изменить одно число в рецепте.
Пакеты собирает робот, живущий на сервере. Если дистрибутив перешел на новую версию системных библиотек, то робот автоматически пересоберёт все пакеты, которые зависят от обновленных библиотек. И при этом ничего в рецепте вообще не придется менять. Это ли не самая удивительная вещь в слитазе?!
Offline
Продолжаю (по ходу дела прошу прощения за множество связных постов и за русизмы, я пишу сейчас из симбиан-смартфона, часто переключать язык неудобно, большое поле редактирования подтормаживает).
Приведенный эксперимент говорит о том, что нахрапом задачу не решить, и что конвертер пакетов это всё же "костыль" (а на костылях далеко не убежишь, только весь измаешься).
Для неподготовленного пользователя весь этот процесс сродни "черному ящику" и на выходе либо получится, либо нет, но вот почему так? Я уже начинаю предпологать, что в этом ящике есть. Пакет это архив, сжатый определенным образом. Там имеются определенные служебные файлы, но основная часть пакета просто распаковывается в вашу файловую систему при установке. Распаковать один архив и упаковать его по-новому несложно. Но вот, достаточно ли этого? В редких случаях, да. Что это за случаи? Это когда в пакете находятся все файлы, необходимые для работы этой программе. Устройство файловой системы во всех линуксах почти стандартизировано, бинарники ложатся в одни папки, библиотеки в другие, значки в третьи. Обычно все эти пути прописаны в системе и портированная программа без труда находит свои части.
А что будет, если программа зависит от других программ? Вот тут ее может постигнуть полный фейл. Можно попробовать установить нужную версию программы. Например, в слитазе широко используется бизибокс, единственный бинарник которого заменяет собой множество линукс-инструментов. Но он работает только с распространенными опциями (ключами) этих программ. Можно попробовать установить оригинальную программу, понимающую все свои ключи.
А как быть с библиотеками? Зачем нужны эти библиотеки, эти зависимости? От них столько проблем ! Авторы программ совершенно не обязаны (даже наоборот) каждый раз изобретать свои велосипеды. Вместо этого они могут использовать отлаженный, вычищенный и вылизанный код библиотек, выполняющий определенные задачи.
Да, это хорошо, это удобно, но вернёмся к нашему конвертеру. Три факта:
[*]Конвертер честно пытается определить зависимости пакета (из тех самых служебных фалов в пакете) и прописать те же зависимости в собираемый пакет. Но названия пакетов в исходном репозитории и в нашем могут не совпадать (большой проект, например, может быть разбит на несколько пакетов по-разному). Можно попробовать исправить ситуацию, разобрав пакет и подправив лежащий в нём (автоматически созданный) рецепт, сверившись с базой данных нашего репозитория.
[*]Зависимости — это не какие-то «сферические кони в вакууме», их тоже люди делают. И переделывают. И выпускают новые версии с закрытием старых ошибок (и написанием новых) и с новыми функциями. Часто может случаться так, что наша система почти целиком и полностью основана на одной версии библиотеки (это можно назвать «глубинной зависимостью»), а для работы новой пересобранной программы нужна более новая версия этой библиотеки. Это скорее исключение из правила, когда две версии одной и той же библиотеки могут ужиться рядом в одной системе. А пересобирать всю систему из-за одной программы? Нет уж…
[*]Скомпилированные бинарники из собранного пакета можно назвать «монументом, застывшим в камне» в отличие от исходников этого же пакета. Всё опять же из-за совместной работы программ. Если наша программа была скомпилирована, скажем, с использованием библиотеки glibc-2.13, то она совершенно определенным и наивным образом предполагает, что она найдет, например, файл libutil-2.13.so (скорее всего в папке /lib) и что, обратившись по определенному адресу она совершенно точно обратится к конкретной процедуре, которая выполнит определенные действия.
Библиотека может, называться, например, libGL.so.1.2 (конкретная указанная версия) и рядом в этой же папке могут лежать libGL.so.1 и libGL.so. Предполагается, что в первом случае программе нужна функция конкретной библиотеки, с точностью до версии; во втором случае — реализация этой функции не критична и может браться из первой ветки библиотеки; в последнем случае — программа использует функцию, которая всегда и «испокон веку» имеется в любой версии-подверсии библиотеки. Но это только мои предположения, авторы программы могут думать по-другому. Вообще же, только файл libGL.so.1.2 по-настоящему является библиотекой, а два оставшихся — только ссылки на нее. Добавим мы, скажем, libGL.so.1.3; а как быть теперь с libGL.so.1 и libGL.so? На что им теперь лучше указывать? Может, «взлетит», а может и нет…
Offline
Ого, сколько я тут написал! Может, оформить как статью на моём полузаброшенном блоге?
Но и это ещё не всё.
Как уже было показано выше товарищем sklimkinым, имеются программы, очень сильно интегрированные в систему. В данном случае, gedit интегрирован в Gnome. Может ли быть такое, что для работы программы, текстового редактора, нужно
294 новых пакетов
? Я что-то сомневаюсь, что кто-то из авторов Gedit‘а способен будет удержать в голове все эти взаимосвязи и пользоваться изнутри Gedit‘а всеми функциями этих 294 пакетов (не в обиду авторам сказано). Скорее всего, он имеет не более чем с десяток зависимостей, как обычная программа. А остальное — зависимости зависимостей и так далее.
alsa-lib-1.0.26.tazpkg
Так ли необходимо текстовому редактору работать со звуком на уровне железа? Сомнительно…
Вот поэтому, в мире маленьких линукс-систем на вес золота программы, содержащие в себе минимум зависимостей и не интегрированные с какой-либо определенной средой. Усилиями энтузиастов таких программ появляется со временем всё больше. Не скажу, что Geany такой уж идеальный и оторванный от всего проект. Но я с успехом использую его (одну и ту же программу, получается) и в Linux Mint, и в SliTaz, и в Windows. Вообще-то это IDE (интегрированная среда разработки), но так как я не совсем разработчик, то я с удовольствием использую Geany как многофункциональный текстовый редактор с подсветкой синтаксиса. Про Gedit, оставленный мною несколько месяцев назад в Linux Mint я и не жалею и не вспоминаю
В общем, может быть, Gedit и можно отучить от Gnome, но как-то это всё лениво делать. Свободное время можно использовать с большей пользой или приятностью. Да и вряд ли кто-то (много ли) скажут спасибо за эту работу
А пакетов в SliTaz не так уж и мало, и постоянно появляются еще и еще. Точной статистики у меня нету, могу лишь посоветовать посмотреть на Hg в разделах wok, wok-stable, wok-undigest и wok-tiny (по дате можно примерно прикинуть), а также в (почти) ежемесячном бюллетене здесь: Monthly Newsletter. Здесь можно найти полный список новых пакетов и сокращенный список обновленных. Есть два-три человека, «собаку съевших» на этих пакетах. Я думаю, что они будут не против добавить в репозиторий какие-нибудь новые реальные вещи. Надо только к ним правильно обратиться (по-английски и вежливо)
Вроде всё. Окончательный вывод, думаю, не будет неожиданностью. Для того, чтобы работали все программы из репозитория Debian, мы должны полностью на нём быть основанными. Наш дистрибутив должен быть собран только из пакетов, имеющихся в этом репозитории (ну, еще можно иметь какие-то свои диалоги-скрипты-настройщики и разные фишки). Но это ведь будет совсем уже не SliTaz!
Надеюсь, что эта моя болтовня была кому-нибудь полезной.
За сим откланиваюсь, искренне ваш,
Offline
Добавить ПОКА нечего, предельно ясные выкладки.
Спасибо Алексей!
Ваши 4 поста в этой теме ОЧЕНЬ многое прояснили (во всяком случае для меня).
1. Стало понятно, почему зацикливаются зависимости даже при установке их по-одной через dpkg.
2. Надо осваивать установку из исходников по описанной Вами схеме - чтобы не ждать чудес и огорчений.
3. Ждать от slitaz поведения, свойственного debian/ubuntu есть заблуждение и даже ересь.
Мне кажется, что для наших европейских соседей английская версия темы может оказаться полезной.
Живой диалог воспринимается лучше, чем сухие технические выкладки - психология однако.
При переводе конечно кое-что потеряется, но зато не потребуется им объяснять почему "до х.." много больше, чем "много"
Я немного читаю, а пишу только "со словарем".
Вы легко пишете по-английски.
Может быть переведете?
Offline
Хм, ну пишу я по-английски где-то на уровне «моя твоя понимайтт». Кое-что приходится тоже переводить гугль-транслейтом. Но для нашего интернационального проекта это типично и никто слова кривого не говорит по поводу плохого слога.
Но вот, что-то я не вижу необходимости заниматься этим переводом. Будет просто еще одна статья, которая потеряется в недрах форума. Да и информации, по большому счету, она не несёт. Так, вольный пересказ имеющейся документации, да свои догадки…
Offline
>мне не хватает дебиановских gedit и gnome-commander (mc в slitaz по умолчанию уж очень убогий).
Удивлен, что у нас нет gedit. В принципе, если не хватает какого-то пакета в cooking, то можете писать мне напрямую - соберу при первой возможности.
Касательно mc - в чем заключается неполноценность?
Offline
> В принципе, если не хватает какого-то пакета в cooking, то можете писать мне напрямую - соберу при первой возможности.
Прошу напрямую: при возможности соберите gnome-commander, он более актуален, чем редактор gedit.
Более того согласен с Алексеем, что в slitaz есть geany, есть и еще один (притом не тяжеловес) - leafpad. Так что с учетом "тяжести" gedit, без него можно обойтись.
А если к сборке приложите логи, то это будет неплохой учебник, притом с конкретикой.
> Касательно mc - в чем заключается неполноценность?
У меня он рассыпается (как сильно пережатый видеоролик) при растягивании/сжатии окна.
То есть в различных местах окна появляются пустые блоки белого цвета вместо символьных элементов.
С таким эффектом столкнулся впервые (пользуюсь им в других Линуксах без проблем).
Установил из репозитория-диска Packages-4.
Offline
>У меня он рассыпается (как сильно пережатый видеоролик) при растягивании/сжатии окна.
Это проблема ncurses скорее всего. Попробую собрать со slang и протестировать.
>при возможности соберите gnome-commander, он более актуален, чем редактор gedit.
Первое - точно да.
Второе - gedit сейчас на gtk3 переехал. Это совсем не есть хорошо.
// Я сам сейчас на slitaz перевожу свой домашний серверок. Гента все-таки оверкилл для него.
Offline
> Касательно mc - в чем заключается неполноценность?
У меня он рассыпается (как сильно пережатый видеоролик) при растягивании/сжатии окна.
То есть в различных местах окна появляются пустые блоки белого цвета вместо символьных элементов.
С таким эффектом столкнулся впервые (пользуюсь им в других Линуксах без проблем).
Установил из репозитория-диска Packages-4.
На вот это не похоже?
[attachment=17400,709]
Это mc, запущенный в xterm с настройками по умолчанию (в chroot-окружении из под root). Здесь проблемы не mc, а xterm (в терминале Sakura, к слову, таких проблем нет).
XTerm по умолчанию не воспринимает UTF-8.
[*]Временное решение — на окне xterm сделать Ctrl + правый клик, отметить галочкой пункт «UTF-8 Encoding».
[*]Постоянное решение — в домашней папке добавить в файл «.Xdefaults» (или «.Xresources», смотря что есть; второй файл более современный, но смысл один и тот же) такую строку: [c]xterm*utf8: 2[/c]
[*]теперь запускайте ваш mc в xterm
Надеюсь, что это именно то, потому что побороть проблемы Curses я не отважусь, да у меня их и нет.
Offline
Aleksej
Спасибо, Алексей.
MidnightCommander преобразился и выводит кириллицу.
devl547
> Второе - gedit сейчас на gtk3 переехал. Это совсем не есть хорошо.
1.5 года назад я ушел из win32 и выбрал ubuntu (так проще переучиваться).
Надоели виндовые гонки (98 2000 XP win7 ...).
Я был удивлен тем, что голая win7 занимала на диске 17 ГБ против 1.5 ГБ win-XP
Но юбунта похоже идет тем же путем.
В ubuntu-10.4 LTS (а выше мне не надо) я уже кое-что не могу скомпилить/установить.
Мне не надо ни KDE ни Unity, GTK2 с Gnome вполне устраивает.
gcc gtkdialog CodeBlocks Glade и XForms, кое-что для cross-compile и виртуальные машинки.
Вот и стал изучать альтернативы, во всем их многообразии ...
Замкнутость двух очень неплохих "маленьких" линуксов только на свои репы меня насторожила.
Вот почему в slitaz я начал с этого вопроса.
Очень порадовала возможность "развернуть" систему на раздел диска (persistent) и затем, при необходимости, свернуть ее во frugal. И даже держать параллельно в одном месте и то и другое и также параллельно иметь возможность их загрузки.
Это реальный простор для экспериментов, пока понимание системы и ее наполнения у меня не устаканятся.
Offline
Начал собирать gnome-commander - выросла феерическая задница с хедерами.
Практически все нужные хедеры лежат по путям типа /usr/include/libgnomeui-2.0/libgnomeui/, хотя должны в /usr/include/libgnomeui/
Плюс в паре пакетов нет нужных хедеров в принципе. Интереснуя задачку задали, спасибо.
Offline
А я собрал и выложил движок equinox и темы к нему. Понемногу учусь собирать пакеты в среде SliTaz.
Так вот, среди тем бóльшую половину занимают темы для metacity. А его у нас, оказывается, и нету. Вот, решил собрать. Уже написан рецепт и уже, наконец то, всё скомпилировалось! ^.^
Осталось дописать в рецепт финал — что забрать в пакет из скомпилированного.
Вопрос к знатокам! Надо ли это нам и как его потом подвязать к системе. Это оконный менеджер, по идее замена OpenBox.
Offline
Скорее openbox - замена metacity, ибо последний - это часть проекта gnome (точнее gnome2).
Закинь в cooking, точно не помешает.
С вами в IM как-нибудь можно связаться?
Offline
Саша, я немного в непонятках.
Я собирал это в стабильной системе. Закидывать, по идее, нужно в wok-stable?
Или по традиции нужно в wok-undigest? (и потом дальше)
Я тут на днях человеку закинул его 4 рецепта в undigest, так появилась куча ошибок. Это может быть как-то связано именно с Undigest? Вроде бы у него всё собиралось нормально (?)
Ты вообще предлагаешь закинуть в Cooking wok… Мне для этого же нужно загрузиться в Cooking? И именно там компилировать? Вроде бы Cooking-система крайне нестабильна, и зачастую не подходит для работы. Не хочется.
PS. В IM‘ах я практически не бываю. Вот по почте — доступен ВСЕГДА (когда не сплю).
Offline
В wok. Оттуда потом в wok-stable пойдет.
>Вроде бы Cooking-система крайне нестабильна
В ней баги фиксят быстрее, чем в stable.
>Мне для этого же нужно загрузиться в Cooking?
Зачем? Просто кинь рецепт в wok и все.
Offline
Хорошо, скоро закину.
>Вроде бы Cooking-система крайне нестабильна
В ней баги фиксят быстрее, чем в stable.
Разные версии ключевых системных библиотек же!
Пока я собирал Metacity мне пришлось нехило откатиться назад по версиям для «gsettings-desktop-schemas», а потом и для самого Metacity. И всё из-за версии GLib.
Offline
Спорить не буду. Мне сидеть на свежем софте привычнее (гентушник же).
Сейчас закину то, что сделал с gnome-commander в рассылку, пусть дальше думают, что делать. А меня на даче ждут)
Offline
# SliTaz package receipt.
PACKAGE="gnome-commander"
VERSION="1.2.8.15"
CATEGORY="utilities"
SHORT_DESC="A full featured, twin-panel file manager for Gnome2"
MAINTAINER="devl547@gmail.com"
TARBALL="$PACKAGE-$VERSION.tar.xz"
WEB_SITE="http://gnaughty.sourceforge.net/"
WGET_URL="http://ftp.gnome.org/pub/GNOME/sources/$PACKAGE/1.2/$TARBALL"
BUILD_DEPENDS="gtk+-dev glib-dev gnome-doc-utils-dev libgnome-dev
libgnomeui-dev gdk-pixbuf-dev cairo-dev pango-dev atk-dev libbonoboui-dev
libgnomecanvas-dev libart_lgpl-dev xorg-libXinerama-dev xorg-libXrandr-dev
xorg-dev libgnome-keyring-dev libgcrypt-dev rarian-dev rarian"
DEPENDS="gtk+ glib gnome-doc-utils libgnome libgnomeui gdk-pixbuf cairo
pango atk libbonoboui libgnomecanvas libart_lgpl xorg-libXinerama
lignome-keyring libgcrypt rarian"
# Rules to configure and make the package.
compile_rules()
{
cd $src
# Quick and dirty headers fix
ln -s /usr/include/gtk-2.0/gdk /usr/include/
cp /usr/include/cairo/* /usr/include/
ln -s /usr/include/pango-1.0/pango /usr/include/
ln -s /usr/include/gdk-pixbuf-2.0/gdk-pixbuf /usr/include/
ln -s /usr/include/gtk-2.0/gtk /usr/include
ln -s /usr/include/atk-1.0/atk /usr/include
ln -s /usr/include/libgnome-2.0/libgnome /usr/include
ln -s /usr/include/libgnomeui-2.0/libgnomeui /usr/include
ln -s /usr/include/libbonobo-2.0/bonobo /usr/include
cp /usr/include/libbonoboui-2.0/bonobo/* /usr/include/bonobo/
ln -s /usr/include/libgnomecanvas-2.0/libgnomecanvas/ /usr/include/
ln -s /usr/include/libart-2.0/libart_lgpl/ /usr/include/
./configure $CONFIGURE_ARGS &&
make && make install
}
# Rules to gen a SliTaz package suitable for Tazpkg.
genpkg_rules()
{
cp -a $install/usr/bin $fs/usr
cp -a $install/usr/share/ $fs/usr/
}
Offline
Что-то никаких специфичных опций рядом с [c]configure[/c], нет даже традиционного [c]--prefix=/usr[/c]. Вечерком гляну...
Offline
>Что-то никаких специфичных опций рядом с configure
Это все давно уже передается через $CONFIGURE_ARGS
Offline
[ Generated in 0.019 seconds, 7 queries executed - Memory usage: 1.65 MiB (Peak: 1.77 MiB) ]