| vadik |
|
|
Темы:
55
Сообщения:
5395
Участник с: 17 августа 2009
|
Тему создаю в этом разделе потому, что не требуется конкретики и допускаются размышления и отступления (с возвратом :)) от первоначальной темы. В общем пока дома нет доступа к интернету, а свободное время хотябы иногда но появляется, решил я позаморачиваться со зборкой пакетов. Ну а чтоб не просто трата времени, а еще и с пользой, захотелось мне помучать k3b который на qt3. Сам по себе пакет не является для меня жизненно важным и необходимым, но зато достаточно сложный, что способствует более углубленному изучению материала. В общем по ходу действия возникают вопросы и один из них следующий. Один пакет, как известно, может быть зависимостью другого пакета и/или сам иметь зависимости, так вот можно ли вкомпилировать зависимости в пакет жестко. Выразился наверное не правильно поэтому постараюсь уточнить задачу. Собираем пакет “А”, у которого в зависимостях имеется пакет “Б”. Сборка пакета происходит удачно, но при установке выясняется что в системе установлен пакет “С” который удалять нельзя и этот пакет (“С”) конфликтует с пакетом “Б”. А пакету “А” для корректной работы нужен именно пакет “Б”. Как я понял в процессе сборки пакетов можно указывать какие пакеты включать “жестко”. Хотелось бы узнать как именно это делать и желательно правильно. |
| mechanical |
|
|
Темы:
16
Сообщения:
663
Участник с: 11 октября 2008
|
А не кажется, что если С конфликтует с Б, то это неспроста, и лучше не ставить их вместе? Тут либо С либо Б И я что-то не могу представить такую ситуацию. Есть живой пример? |
| vadik |
|
|
Темы:
55
Сообщения:
5395
Участник с: 17 августа 2009
|
mechanicalКажется. Поэтому и спрашиваю можно ли вкомпилить Б в А чтобы С не использовался. (Согласен звучит немного пошло) mechanicalЯ ж и написал k3b который на qt3 |
| mechanical |
|
|
Темы:
16
Сообщения:
663
Участник с: 11 октября 2008
|
Вообще “вкомпиливание Б в А” не решает проблему конфликта, мы просто формально убираем упоминание пакета Б, но файлы его (или другие ресурсы) от этого не перестают сущестовать. Пакеты например могут конфликтовать, если они по сути являются одним и тем же (например cairo и cairo-cleartype), в этом случае есть conflicts= и provides= Напиши конкретно, что есть А Б С в случае с k3b на qt3 |
| vadik |
|
|
Темы:
55
Сообщения:
5395
Участник с: 17 августа 2009
|
Пакет собирал дома поэтому могу ошибаться. Помоему загвоздка была в libdvdread3, в системе установлен libdvdread4. Вот и появилась мысля заставить k3b использовать libdvdread3 именно таким способом (дабы он и не пытался обращаться к пакету установленному в системе). Гдето читал что можно при сборке пакетов зависимости включать статически. |
| mechanical |
|
|
Темы:
16
Сообщения:
663
Участник с: 11 октября 2008
|
что значит включать зависимость статически, я плохо понимаю: 1)либо это означает статически указать версию пакета в depends=() 2) либо убрать зависимость от этого пакета из depends, и собрать его в том же PKGBUILD (т.е. сделать несколько configure и make в пределах одного PKGBUILD ) Но при этом, нужно четко представлять какие файлы и куда будут ложится, и лучше всего отделить свой пакет от /usr и класть его в /opt (–prefix=/opt/…) как делает, например, kdemod и кстати, сейчас смотрю PKGBUILD kdemod3-k3b, так там не зацикливаются на версии libdvdread |
| vadik |
|
|
Темы:
55
Сообщения:
5395
Участник с: 17 августа 2009
|
Да в том то и дело что пакет собирается нормально и даже устанавливается (если убрать из списка зависимостей конфликтующие пакеты). Но работать он, естественно, не будет, потому как для работы того-же k3b нужен пакет 3-й версии, а в системе установлен пакет 4-й версии. Вот мне и интересно, можно ли добавить libdvdread3 таким образом чтобы k3b обращался именно к нему, а не к установленному в системе (грубо говоря - включить libdvdread3 в состав k3b). Собственно еще одна причина по которой хотелось бы разобраться с процессом сборки пакетов - хочу сделать для себя интернетНЕзависимую систему с интернетНЕзависимым набором програм. Т.е. хочу понять возможно ли скачивать и использовать новые/старые версии прикладных программ без необходимости апгрейда/даунгрейда всей системы. Для примера amarok1 из AUR. |
| mechanical |
|
|
Темы:
16
Сообщения:
663
Участник с: 11 октября 2008
|
vadik mechanical или я что-то не учел? в общем, я понимаю твою чисто теоретическую задачку так В системе стоит B_New, а мы хотим поставить пакет A, который будет использовать B_old И чисто теоретический ответ: делаем PKGBUILD depends=(отсюда убираем упоминание про “B”) build() { cd A ./configure –prefix=/opt/.. make make install … cd B_old ./configure –prefix=/opt/… make make install … } Опять же - голая теория, но как минимум разделяем файлы для B_new и B_old |
| vadik |
|
|
Темы:
55
Сообщения:
5395
Участник с: 17 августа 2009
|
mechanicalЭто все правильно до того момента, пока собираемому покету не потребуются какие-то возможности из пакета B_old которых нет/по другому_называются/иначе_реализованы в пакете B_New. mechanicalСовершенно верно, вопрос больше теоретический просто k3b приведен в качестве реального примера, ну и заодно на нем смогу потестить. Кстати, а где можно взять PKGBUILD kdemod3-k3b? |
| mechanical |
|
|
Темы:
16
Сообщения:
663
Участник с: 11 октября 2008
|
vadikmechanicalЭто все правильно до того момента, пока собираемому покету не потребуются какие-то возможности из пакета B_old которых нет/по другому_называются/иначе_реализованы в пакете B_New. то, что мы убираем B из depends никак не влияет на использование приложенем A библиотек B_old. depends=() - это массив пакетов, существование которых в системе проверяет пакман, перед тем как установить пакет A. Проще условно рассматривать depends=() как директиву для pacman. А убираем мы B из depends, потому что B соберется в пакете A http://aur.archlinux.org/packages/kdemo … b/PKGBUILD |