пакетные менеджеры

Любые разговоры которые хоть как-то связаны с тематикой форума

Модератор: Модераторы разделов

Ответить
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

пакетные менеджеры

Сообщение KiWi »

Может, конечно, странного хочу...

Часть будет описываться в терминах, используемых в Gentoo.

Имеем задачи:
1. полное конфигурирование пакетов(все явки и пароли).
2. без необходимости ручного создания пакетов для pear/cpan.
3. как следствие -- появление нормальных мета-пакетов и алиасов.
4. обновлять SVN и прочие Live-пакеты на автомате.
5. узнавать о конфликтах USE-флагов ДО начала компиляции пакета.
6. развитую систему бинарных пакетов, соответственно, более-менее классическое определение релизов.
7. ориентированность на несколько источников пакетов.
8. локальные USE-флаги, которые нужно явно задавать для пакета(так как local.use в зависимости от пакета может менять своё значение), также USE-флаги, не требующие пересборки пакета(например, добавляется только какой-то зависимый пакет).

Код:

package.espec: Name: (auto) -- только для бинарных пакетов Type: package|alias|meta|manager License: GPL-2 Homepage: http://www.epkg.org/ Description: abcd efgh Repository: (auto) -- адрес репозитория, только для бинарных пакетов Maintainer: John Smith [www@example.com] Slots: -- если не задано, то все версии идут в 0 слот, задаётся в виде -- номер версия версия... 5 5* 4 4* Version: (auto) -- только для бинарных пакетов Revision: (auto) -- только для бинарных пакетов Revision-Type: none|config|install|all -- что изменилось(конфигурация, установка, и то, и другое, ничего принципиального) Revision-Date: 2009-08-07 -- дата выходы Release: any|release -- в каких дистрибутивах работает Arch: x86 ~amd64 !ia64 -mips -- стабильные -- без отметок, нестабильные -- ~, в процессе создания пакета -- !, точно не работает -- - Use: .bc mysql pgsql sql docs? -- . -- локальный, ? -- не требует переустановки(зависимости изменились и тп) Use-Check: (mysql|pgsql)&sql -- проверка конфликтов, | -- только ОДИН из нескольких, || -- как минимум один, && -- оба Depend: sql?? php-sql[$mysql $pgsql] -- ?? -- для модулей в основном -- либо добавляет сам поддержку(из исходников), либо через другой пакет(бинарные пакеты и уже установленные исходники, чтобы не пересобирать), $ -- текущее значение флага, [] -- с включенными/выключенными флагами RuntimeDepend: php-cgi CompileDepend: php-dbg Provide: virtual/mta -- реализует mta Binary: -- только для бинарных пакетов, варианты -- Binary-Live, Source, Source-Live Use: bc pgsql -mysql sql docs -- флаги, с которыми создан пакет URL: http://www.epkg.org/pkg.ebin [pkg.ebin] -- адрес пакета, [] -- локальное имя package.econf: -- sh-скрипт sys_config() -- конфиг системы(пути, пользователи, группы) pkg_config() -- конфиг проги sys_clean() -- удаление системных конфигов pkg_clean() -- удаление/перемещение конфигов проги src_espec() -- получение espec-файла(в основном для manager и live-версий при необходимости) package.src.econf: -- sh-скрипт для установки из исходников src_fetch() -- скачивание src_unpack() -- распаковывание, патчи src_configure() -- конфигурация src_compile() -- компиляция src_install() -- образ для установки в систему


В стадии жестокого обдумывания, довольно на скорую руки, так что могло остаться много неясного. Интересует мнение в основном насчёт актуальности задач.
Спасибо сказали:
Аватара пользователя
/dev/random
Администратор
Сообщения: 5289
ОС: Gentoo

Re: пакетные менеджеры

Сообщение /dev/random »

KiWi писал(а):
09.08.2009 13:03
5. узнавать о конфликтах USE-флагов ДО начала компиляции пакета.

В gentoo уже есть (в EAPI 2, правда, на него ещё не все ебилды перешли)

KiWi писал(а):
09.08.2009 13:03
7. ориентированность на несколько источников пакетов.

В смысле?

KiWi писал(а):
09.08.2009 13:03
8. локальные USE-флаги, которые нужно явно задавать для пакета(так как local.use в зависимости от пакета может менять своё значение),

/etc/portage/package.use либо /etc/paludis/use.conf

KiWi писал(а):
09.08.2009 13:03
также USE-флаги, не требующие пересборки пакета(например, добавляется только какой-то зависимый пакет).

Блин, как я этого жду!!!

KiWi писал(а):
09.08.2009 13:03
В стадии жестокого обдумывания, довольно на скорую руки, так что могло остаться много неясного. Интересует мнение в основном насчёт актуальности задач.

Это просто на уровне идей или будет реализовыватся?
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

/dev/random писал(а):
09.08.2009 13:52
В смысле?

Основной portage всегда имеет наивысший приоритет. И версии сравниваются исключительно по номеру и ревизии, не учитывая, что в каждом репозитории могут быть свои ревизии.

/etc/portage/package.use либо /etc/paludis/use.conf

package.use -- добавляет флаг к пакету, тот же флаг можно спокойно добавить и в make.conf, но не об этом речь.
Из /usr/portage/profiles/use.local.desc:

Код: Выделить всё

app-text/lodgeit:vim -  Install a vim plugin allowing to paste and download from within vim
app-text/wklej:vim - Install vim plugin allowing to paste from vim by :Wklej
dev-lang/lisaac:vim - install a syntax file for vim
dev-util/global:vim - Integrate the GNU GLOBAL source code tag system with Vim

Флаг один, а значения -- несколько разные.

Блин, как я этого жду!!!

В принципе, если постараться -- то это можно делать автоматом(хотя, не факт, что получится).

Это просто на уровне идей или будет реализовыватся?

Скажем так -- при наличии времени(проблем с которым пока не намечается), а также -- довольно подробной и "красивой" тех. документации -- будет реализовываться.

Бинарные пакеты(в принципе, возможен вариант и с пакетом из исходников, чтобы не привязываться с дереву со всеми пакетами) -- архив из 2 частей -- необходимого минимума для сборки данного типа пакета(espec, econf, контрольные суммы, подписи).

В принципе даже возможно существование 2 типа распространения -- аналогов portage tree и debian/ubuntu списков пакетов -- один больше для девелоперов(чтобы лишнее не держать), второй -- для юзеров, чтобы не жрать трафик.

Касательно конфигов -- есть идея держать конфиги в XML, потому что валидность можно проверить(тот же relax-ng), да и преобразовать к нужному виду не составит труда -- XSLT.
Спасибо сказали:
Civil
Сообщения: 199
ОС: Gentoo Current

Re: пакетные менеджеры

Сообщение Civil »

1. полное конфигурирование пакетов(все явки и пароли).

emerge --config (например для mysql)

3. как следствие -- появление нормальных мета-пакетов и алиасов.

Чем ненормальны set'ы и virtual-пакеты?

4. обновлять SVN и прочие Live-пакеты на автомате.

emerge @live-rebuild ?

5. узнавать о конфликтах USE-флагов ДО начала компиляции пакета.

EAPI2

6. развитую систему бинарных пакетов, соответственно, более-менее классическое определение релизов.

Зачем?
"Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым" (Д. Оруэлл "1984")
Спасибо сказали:
Аватара пользователя
/dev/random
Администратор
Сообщения: 5289
ОС: Gentoo

Re: пакетные менеджеры

Сообщение /dev/random »

KiWi писал(а):
09.08.2009 14:24
Касательно конфигов -- есть идея держать конфиги в XML

Не понимаю этого всеобщего помешательства на XML. Конфиги бывает нужно вручную править. Неужели кто-то считает, что XML удобно править?
Спасибо сказали:
gultyai
Сообщения: 15
ОС: windows XP+mandriva 2008pp

Re: пакетные менеджеры

Сообщение gultyai »

/dev/random писал(а):
09.08.2009 15:06
Не понимаю этого всеобщего помешательства на XML. Конфиги бывает нужно вручную править. Неужели кто-то считает, что XML удобно править?


А можно ли вообще XML применять? На ЛОРе есть что M$ его запатентовал. Только не понял что: свой новый формат в 2007 офисе или вообще XML?
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

Civil писал(а):
09.08.2009 14:48
emerge --config (например для mysql)

1. Конфигурация выполняется уже ПОСЛЕ сборки и это не будет путём по умолчанию, в случае mysql это может не будет проблемой(хотя, если переместить socket-файл -- скорее всего, будет), а в случае других вещей -- это приведёт к невозможности изменения путей до конфигов(кое-где они жестко прописываются в исходники и НИКАК не меняются).
2. Оно появилось не так давно, так что нормального --config практически нигде нет(в том же mysql пользователь не меняется, а если менять в конфиге, то останется ненужный дефолтный mysql).

Чем ненормальны set'ы и virtual-пакеты?

set'ы -- опять-таки EAPI2. virtual-пакеты до сих вписываются в db как установленные -- нафиг надо? он как бы всё-таки virtual.

emerge @live-rebuild ?

Хорошо, а если я хочу, чтобы все live-версии, которые не обновлялись 2 недели, были обновлены вместе со всеми остальными пакетами? Более того, насколько я помню, все live не имеют нормальной версионности -- типа номер ревизии и тп, так что автоматом узнать стоит ли пересобирать пакет -- нельзя.

Зачем?

Чтобы не собирать пакеты, у которых нет use-флагов/используются стандартные use-флаги ставились быстро и без проблем.
Про deb-src и прочие -- я в курсе, но там есть одно маленькое НО -- нет use-флагов, а как следствие, и все пляски с возможными проблемами(в том числе с зависимостями) -- исключительно в твоих руках.

/dev/random писал(а):
09.08.2009 15:06
Не понимаю этого всеобщего помешательства на XML. Конфиги бывает нужно вручную править. Неужели кто-то считает, что XML удобно править?

Вот только с XML удобно работать на автомате, со всем остальным -- не всегда. А править -- в зависимости от того, насколько глобальна правка. Заменить одно значение не составляет труда в ЛЮБОМ конфиге.

А можно ли вообще XML применять? На ЛОРе есть что M$ его запатентовал. Только не понял что: свой новый формат в 2007 офисе или вообще XML?

XML -- разработка W3C.
Спасибо сказали:
Аватара пользователя
/dev/random
Администратор
Сообщения: 5289
ОС: Gentoo

Re: пакетные менеджеры

Сообщение /dev/random »

gultyai писал(а):
09.08.2009 15:12
А можно ли вообще XML применять? На ЛОРе есть что M$ его запатентовал. Только не понял что: свой новый формат в 2007 офисе или вообще XML?

Там запатентовали не XML, а возможность сохранения документа в один большой XML.

KiWi писал(а):
09.08.2009 15:19
Вот только с XML удобно работать на автомате, со всем остальным -- не всегда. А править -- в зависимости от того, насколько глобальна правка. Заменить одно значение не составляет труда в ЛЮБОМ конфиге.

ИМХО, нормальный конфиг должно быть удобно перерабатывать полностью. И он должен быть подробно откомментирован изнутри, что для XML хоть и возможно, но представляет собой серьёзную проблему.
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

/dev/random писал(а):
09.08.2009 15:35
ИМХО, нормальный конфиг должно быть удобно перерабатывать полностью. И он должен быть подробно откомментирован изнутри, что для XML хоть и возможно, но представляет собой серьёзную проблему.

а) в XML есть комментарии и никакой "серьезной" проблемы это не представляет(для примера можно посмотреть на icecast -- у него конфиги как раз в XML);
б) на основе XML может генерироваться ВСЁ, что угодно, с комментариями и без них.
Спасибо сказали:
Аватара пользователя
Bluetooth
Сообщения: 4395
Статус: Блюзовый
ОС: Debian Squeeze amd64

Re: пакетные менеджеры

Сообщение Bluetooth »

KiWi писал(а):
09.08.2009 15:44
/dev/random писал(а):
09.08.2009 15:35
ИМХО, нормальный конфиг должно быть удобно перерабатывать полностью. И он должен быть подробно откомментирован изнутри, что для XML хоть и возможно, но представляет собой серьёзную проблему.

а) в XML есть комментарии и никакой "серьезной" проблемы это не представляет(для примера можно посмотреть на icecast -- у него конфиги как раз в XML);
б) на основе XML может генерироваться ВСЁ, что угодно, с комментариями и без них.

а) А однострочные камменты есть?
б) Можно. И нужно. Тогда будет удобно редактировать. Только мне не до конца ясно, зачем тогда вообще хмл?
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

Bluetooth писал(а):
09.08.2009 15:56
а) А однострочные камменты есть?

Нет. Только с открывающим и закрывающим тегом. Лично мне 3 символа погоды не делают.
б) Можно. И нужно. Тогда будет удобно редактировать. Только мне не до конца ясно, зачем тогда вообще хмл?

Не всё может быть реализована в пределах скрипта, так что возможность отключения автоконфигурирования должна быть.
Спасибо сказали:
Civil
Сообщения: 199
ОС: Gentoo Current

Re: пакетные менеджеры

Сообщение Civil »

1. Конфигурация выполняется уже ПОСЛЕ сборки и это не будет путём по умолчанию

Не понимаю проблемы. Как-то жили и живем без этого. Не могу представить ситуацию, когда подобные действия могут понадобится.

Оно появилось не так давно

Если мне память не изменяет, то года 3 или 4 назад появилось. Есть как минимум у апача и mysql.

Чтобы не собирать пакеты, у которых нет use-флагов/используются стандартные use-флаги ставились быстро и без проблем.

Какова идеология Gentoo? Оффициальная, я имею в виду. И объясните как эта идея соотносится с оффициальной идеологией? Опять же, если на то пошло, чем в таком случаи не подходят binpkg?

Более того, насколько я помню, все live не имеют нормальной версионности -- типа номер ревизии и тп, так что автоматом узнать стоит ли пересобирать пакет -- нельзя.

С попытками узнать версию есть огромная масса проблем. Потенциальное отсутствие интернета, дороговизна трафика или закрытые порты у некоторых юзеров. Плюс для всего обилия систем неплохо бы предложить способ узнать текущую ревизию без обновления репозитория. Опять же Live-версии не поддерживаются и никогда не будут поддерживаться разработчиками, просто по определению. Кто их использует - сам виноват и сам должен с ними разбираться как ему хочется.
"Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым" (Д. Оруэлл "1984")
Спасибо сказали:
Аватара пользователя
Bluetooth
Сообщения: 4395
Статус: Блюзовый
ОС: Debian Squeeze amd64

Re: пакетные менеджеры

Сообщение Bluetooth »

KiWi писал(а):
09.08.2009 16:04
Bluetooth писал(а):
09.08.2009 15:56
а) А однострочные камменты есть?

Нет. Только с открывающим и закрывающим тегом. Лично мне 3 символа погоды не делают.
б) Можно. И нужно. Тогда будет удобно редактировать. Только мне не до конца ясно, зачем тогда вообще хмл?

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

А мне лично 6 символов на каммент вместо одного в баше и двух в си делают большую погоду. Меня это раздражает.

Про автоконфигурирование не понял :(
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

Если мне память не изменяет, то года 3 или 4 назад появилось. Есть как минимум у апача и mysql.

В таком случае -- не так активно используется и пересчитать приложения можно по пальцам(лень лазить в историю, а сообщения о emerge --config появились, может, год назад).

Какова идеология Gentoo? Оффициальная, я имею в виду. И объясните как эта идея соотносится с оффициальной идеологией? Опять же, если на то пошло, чем в таком случаи не подходят binpkg?

Это вполне себе configurable -- конфигурировать ровно то, что нужно конфигурировать и ничего больше.

С попытками узнать версию есть огромная масса проблем. Потенциальное отсутствие интернета, дороговизна трафика или закрытые порты у некоторых юзеров. Плюс для всего обилия систем неплохо бы предложить способ узнать текущую ревизию без обновления репозитория. Опять же Live-версии не поддерживаются и никогда не будут поддерживаться разработчиками, просто по определению. Кто их использует - сам виноват и сам должен с ними разбираться как ему хочется.

Давайте так -- те, у кого нет инета/дорогой трафик, не используют live-версии, а предпочитают фиксированные версии(притом, во многих случаях -- бинарные). А ещё не стоит забывать, что сейчас мы говорим о менеджере пакетов, а не о поддерживаемости/неподдерживаемости самой программы.

Bluetooth писал(а):
09.08.2009 16:50
Про автоконфигурирование не понял :(

Хочет -- настраивает руками, хочет -- автоконфигурирование.
Притом, так как процесс настройки разделён на 2 этапа -- можно настраивать руками всё и вся(и системные настройки, и программу), а можно что-то одно.
Спасибо сказали:
Civil
Сообщения: 199
ОС: Gentoo Current

Re: пакетные менеджеры

Сообщение Civil »

Это вполне себе configurable -- конфигурировать ровно то, что нужно конфигурировать и ничего больше.

that can be automatically optimized and customized for just about any application or need подразумевает пересборку из сырцов. Поэтому бинарные пакеты в Gentoo всегда были постольку поскольку. Более того, так и будет, потому что бинарники не вписываются в идеологию системы.

В таком случае -- не так активно используется и пересчитать приложения можно по пальцам(лень лазить в историю, а сообщения о emerge --config появились, может, год назад).

Насколько я помню раньше, просто недавно это стало для некоторых пакетов обязательным. Опять же по идеологии Gentoo не должна быть легкой и дружественной, поэтому emerge --config так и остается лишь для единичных пакетов. Опять же как представляется поведение автоконфигуратора? Он не вписывается в термин "Extreme configurability".

А ещё не стоит забывать, что сейчас мы говорим о менеджере пакетов, а не о поддерживаемости/неподдерживаемости самой программы.

Не имеет смысл делать что-то для целого класса неподдерживаемых ебилдов. С такими вещами должны разбираться те, кто их ставят, а не авторы системы пакетов.

p.s. кстати ещё про сэты и мета-пакеты - в одной из следующих версих разработчики хотят сэты сильно расширить, так что надобность в каком-то огороде почти наверняка отпадет.
p.s.s. и всё же я хочу услышать что значит "нормальные мета-пакеты" и чем они отличаются от сэтов или текущих мета-пакетов
"Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым" (Д. Оруэлл "1984")
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

Civil писал(а):
09.08.2009 19:18
p.s.s. и всё же я хочу услышать что значит "нормальные мета-пакеты" и чем они отличаются от сэтов или текущих мета-пакетов

Сэты -- это как раз нормальные мета-пакеты...
Спасибо сказали:
Аватара пользователя
Bluetooth
Сообщения: 4395
Статус: Блюзовый
ОС: Debian Squeeze amd64

Re: пакетные менеджеры

Сообщение Bluetooth »

KiWi писал(а):
09.08.2009 17:10
Хочет -- настраивает руками, хочет -- автоконфигурирование.
Притом, так как процесс настройки разделён на 2 этапа -- можно настраивать руками всё и вся(и системные настройки, и программу), а можно что-то одно.

Это я понял, я не понял нафиг нужен хмл. Он нужен, чтобы людям было менее комфортно редактировать? :)
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

Bluetooth писал(а):
09.08.2009 19:44
KiWi писал(а):
09.08.2009 17:10
Хочет -- настраивает руками, хочет -- автоконфигурирование.
Притом, так как процесс настройки разделён на 2 этапа -- можно настраивать руками всё и вся(и системные настройки, и программу), а можно что-то одно.

Это я понял, я не понял нафиг нужен хмл. Он нужен, чтобы людям было менее комфортно редактировать? :)

Ок, поясняю.
Есть XML -- его основное назначение -- автоматизированная настройка. На основе XML генерятся все остальные файлы.
Почему XML?
- можно завернуть любой формат конфига
- можно его проверить(relax-ng и прочие схемы для валидации)
- можно преобразовать в любой нужный формат(xslt)
- с ним удобно работать -- есть соответствующие библиотеки(писать для каждого конфига свой парсер -- самоубийство)

Редактируется XML в первую очередь софтом(apacheconf vhost add example.com, например), юзер лезет туда только в крайнем случае.

Этот самый XML можно тупо отключить(то есть указать, что такой-то, такой-то и такой-то файлы редактируются ТОЛЬКО вручную). После этого файл редактируется как душе угодно.

Более того, для некоторого софта XML-генерация не очень удобна(тот же wgetrc легче руками править), соответственно, туда XML-конфигуратор не приделывается/приделывается от нечего делать.

P.S.: есть мнение, что init-скрипты -- проблема не пакета, а init-системы, потому что
а) init-система может стоять любая и включать скрипт для какой-то одной системы -- неразумно, для нескольких -- невыгодно, ибо будут пылиться;
б) часть init-скриптов не используется.
Спасибо сказали:
Аватара пользователя
Bluetooth
Сообщения: 4395
Статус: Блюзовый
ОС: Debian Squeeze amd64

Re: пакетные менеджеры

Сообщение Bluetooth »

KiWi писал(а):
09.08.2009 21:44
Bluetooth писал(а):
09.08.2009 19:44
KiWi писал(а):
09.08.2009 17:10
Хочет -- настраивает руками, хочет -- автоконфигурирование.
Притом, так как процесс настройки разделён на 2 этапа -- можно настраивать руками всё и вся(и системные настройки, и программу), а можно что-то одно.

Это я понял, я не понял нафиг нужен хмл. Он нужен, чтобы людям было менее комфортно редактировать? :)

Ок, поясняю.
Есть XML -- его основное назначение -- автоматизированная настройка. На основе XML генерятся все остальные файлы.
Почему XML?
- можно завернуть любой формат конфига
- можно его проверить(relax-ng и прочие схемы для валидации)
- можно преобразовать в любой нужный формат(xslt)
- с ним удобно работать -- есть соответствующие библиотеки(писать для каждого конфига свой парсер -- самоубийство)

Редактируется XML в первую очередь софтом(apacheconf vhost add example.com, например), юзер лезет туда только в крайнем случае.

Этот самый XML можно тупо отключить(то есть указать, что такой-то, такой-то и такой-то файлы редактируются ТОЛЬКО вручную). После этого файл редактируется как душе угодно.

Более того, для некоторого софта XML-генерация не очень удобна(тот же wgetrc легче руками править), соответственно, туда XML-конфигуратор не приделывается/приделывается от нечего делать.

Черт, я, видимо, не понимаю сути вопроса. ХМЛ будет использоваться где? Я просто думал, что имеется ввиду использование ХМЛ для конфигов к пакетам(то есть я имею ввиду файлы для того, чтобы в них хранить инфу о том, как собрать пакет)
Но тут я вижу что-то более грандиозное, но не понимаю - что же это :crazy:
Спасибо сказали:
Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 8259
Статус: Маньяк
ОС: Arch, Fedora, Ubuntu
Контактная информация:

Re: пакетные менеджеры

Сообщение serzh-z »

KiWi писал(а):
09.08.2009 13:03
Интересует мнение в основном насчёт актуальности задач.
Велосипеды, велосипеды... Вот она - жизнь человека: бесконечная дорожка из сломанных велосипедов. :( И правда - странного, но не оригинального, хочешь.

Но кроме шуток - не увидел цели в перечислении задач: ты хочешь сделать свой пакетный менеджер? Почему бы тогда вместо определения типичных, с твоей точки зрения, цельных задач, не сосредоточиться на определении точек подключения модулей для решения неких задач? Скажем - точка подключении модуля, решающего задачу "где взять", или точка для модулей - "что сделать", или "как сделать", "с каким приоритетом" и т.д. Главная проблема - определить эти точки и их назначение.

Bluetooth писал(а):
10.08.2009 01:15
Но тут я вижу что-то более грандиозное, но не понимаю - что же это crazy.gif
Сферический... нет, не конь... пакетный менеджер. ;)
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

serzh-z писал(а):
10.08.2009 02:02
Но кроме шуток - не увидел цели в перечислении задач: ты хочешь сделать свой пакетный менеджер? Почему бы тогда вместо определения типичных, с твоей точки зрения, цельных задач, не сосредоточиться на определении точек подключения модулей для решения неких задач? Скажем - точка подключении модуля, решающего задачу "где взять", или точка для модулей - "что сделать", или "как сделать", "с каким приоритетом" и т.д. Главная проблема - определить эти точки и их назначение.

Скажем так -- сюда вынесено что-то больше похожее на результат. Всё начиналось с листка бумаги, на котором перечислялось -- как устанавливается тот или иной пакет(make,automake,cpan,pear,bin и т.д. и т.п.), оттуда уже выдиралось -- а что нам лучше знать, что мы можем поменять, что общего и т.п. Это касаемо пакетов. Касаемо своего менеджера -- было расписано в какой последовательности всё происходит, какие данные берутся, откуда и т.п.
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

После просмотра exherbo -- появилось несколько идей... А ещё небольшой камень в portage -- они усложняют синтаксис(для @sets можно было обойтись обычными пакетами).
Спасибо сказали:
Civil
Сообщения: 199
ОС: Gentoo Current

Re: пакетные менеджеры

Сообщение Civil »

KiWi
для @sets можно было обойтись обычными пакетами

Дык мета-пакеты. Вот так вот можно было обойтись обычными пакетами.

serzh-z
+1
"Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым" (Д. Оруэлл "1984")
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

Civil писал(а):
10.08.2009 17:52
Дык мета-пакеты. Вот так вот можно было обойтись обычными пакетами.

У обычных "мета"-пакетов ничего кроме набора зависимостей не было.
А набор зависимостей представляет из 2 проблемы: удаление самого мета-пакета приведет к интересным последствиям(особенно, при запуске depclean), а также -- нельзя удалить одну из частей мета-пакета -- она потом снова установится... Из-за зависимостей.
Вот только создатели portage вместо допиливания текущей реализации решили извратиться и создали sets.
Спасибо сказали:
Civil
Сообщения: 199
ОС: Gentoo Current

Re: пакетные менеджеры

Сообщение Civil »

KiWi
Мета-пакеты это отдельная сущность, требующая отдельной реализации. Старые меты - это просто обычный пакет с пустым install'ом, compile'ом и unpack'ом. Как ни крути, а для них нужен отдельный случай. Вообще они вроде хотели сделать отдельный флаг Meta типа TYPE="Meta" или что-то в таком духе. Хотя не помню что с этим хотением стало. В том, что последует за EAPI2 или EAPI3 будет достаточное колличество изменений.
К слову EAPI3
"Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым" (Д. Оруэлл "1984")
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

Civil писал(а):
10.08.2009 22:44
KiWi
Мета-пакеты это отдельная сущность, требующая отдельной реализации. Старые меты - это просто обычный пакет с пустым install'ом, compile'ом и unpack'ом. Как ни крути, а для них нужен отдельный случай. Вообще они вроде хотели сделать отдельный флаг Meta типа TYPE="Meta" или что-то в таком духе. Хотя не помню что с этим хотением стало. В том, что последует за EAPI2 или EAPI3 будет достаточное колличество изменений.
К слову EAPI3

Нужен. Про это и речь. И видится мне -- добавить проверку, чтобы в случае type='meta' вместо самого пакета в user-selected добавлялся список зависимостей -- легче, чем вводить новую сущность в виде sets, добавить парсинг конфигов для этих самых sets и прочее и прочее. Более того, введение типа даст потенциальные возможности к расширению возможостей БЕЗ необходимости создания новых сущностей.

А так -- видится некий разнобой в том, что делают с EAPI -- тоже _одновременное_ введение src_prepare & default_ -- идиотизм. src_prepare создаётся для того, чтобы не переписывать дефолтный src_unpack... Но, имея в руках default_, почему бы не переделать src_unpack в

Код: Выделить всё

src_unpack() {
default
patch
patch
}


Ведь именно этого хотели добиться, вводя src_prepare.

P.S.: хотя, учитывая OpenRC 0.5.0, неожиданно. -- совершенно нормальное явление.
Спасибо сказали:
Civil
Сообщения: 199
ОС: Gentoo Current

Re: пакетные менеджеры

Сообщение Civil »

KiWi
А так -- видится некий разнобой в том, что делают с EAPI -- тоже _одновременное_ введение src_prepare & default_ -- идиотизм. src_prepare создаётся для того, чтобы не переписывать дефолтный src_unpack... Но, имея в руках default_, почему бы не переделать src_unpack в

Не стоит называть нецелевое использование default'а при наличии src_prepare идиотизмом (да, это идиотизм, но того кто до такого додумался, а не авторов функционала). Они для разных целей были введены. src_prepare просто повышает читабельность. А default'ы в том же src_unpack'е нужны для пакетов со сложной структурой (если нужно дополнить по какой-то причине стандартный unpack ещё чем-то).
"Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым" (Д. Оруэлл "1984")
Спасибо сказали:
Аватара пользователя
KiWi
Бывший модератор
Сообщения: 2521
Статус: статус, статус, статус
Контактная информация:

Re: пакетные менеджеры

Сообщение KiWi »

Civil писал(а):
11.08.2009 07:25
Не стоит называть нецелевое использование default'а при наличии src_prepare идиотизмом (да, это идиотизм, но того кто до такого додумался, а не авторов функционала). Они для разных целей были введены. src_prepare просто повышает читабельность. А default'ы в том же src_unpack'е нужны для пакетов со сложной структурой (если нужно дополнить по какой-то причине стандартный unpack ещё чем-то).

С вами разговор окончен, ибо не о чем.
Можете на досуге почитать какой смысл вкладывается в src_prepare: http://ciaranm.wordpress.com/2008/09/29/eapi-2-src_prepare/ -- найдёте хоть слово про читабельность -- приходите.
Спасибо сказали:
Civil
Сообщения: 199
ОС: Gentoo Current

Re: пакетные менеджеры

Сообщение Civil »

KiWi
This function is purely for convenience. It gets rather tedious copying out the default implementation of src_unpack just to add a patch in somewhere.

Так что уж простите, но именно у Вас отсутствует представление о том зачем и для чего что-то было сделано. Потому как то что тут написано как бы не соотносится с тем, что писали Вы. Сами же приводите опровержения своих слов. И по сути подтверждение моих. Так что да, Вы правы, говорить с Вами не о чем, пока у Вас не будет хотя бы малейшего представления о написании ебилдов, о правилах написания, о том что такое и для чего нужны различные EAPI. Так что извиняйте, как прочитаете - так можете уже и предлагать свои усовершенствования.
"Кто управляет прошлым, тот управляет будущим; кто управляет настоящим, тот управляет прошлым" (Д. Оруэлл "1984")
Спасибо сказали:
Ответить