The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Представлена первая бета-версия pkgng, нового пакетного мене..., opennews (??), 02-Фев-12, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


229. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от vle (ok), 04-Фев-12, 12:18 
>> Никогда не понимал людей, которые пишут такие вещи на С
> насколько я понимаю, pkgng - не надстройка, а полная замена всех pkg_*
> утилей, причем на уровне базовой системы. На чем это может быть
> написано кроме С - не представляю.

Судя по ману это не столько замена pkg_install, сколько претензия на yum/apt.
В одном флаконе так сказать.
В pkgsrc pkg_install написан на С и кода примерно 14000 строк,
то есть в 3 раза меньше, это если не считать совершенно неуместного
здесь sqlite3. Если с ним, то получается в 13(!!!) раз меньше кода.
pkgsrc-ый pkg_install -- это примерный аналог dpkg/rpm, (только лучше :-) )
Этой базы достаточно для написания поверх нормального high-level менеджера пакетов.
Свой NIH я написал на шеле, это примерно 4000 строк, функций больше, чем в pkgng
и pkgin (тоже для pkgsrc, но написан на С).
http://github.com/cheusov/pkgnih
Такой подход мне кажется более правильным, при условии, конечно,
что обновление самого себя не является проблемой.
База -- на С, обертка -- на шеле. По-моему так правильнее.

>> К тому же с этой штукой пропадает разделение на два уровня:
>> низкоуровневое управление пакетами и высокоуровневое
>> (a la rpm / yum|apt или dpkg / apt|aptitude).
> Гммм... что Вы понимаете под словами "низко" и "высоко"-уровневое управление пакетами?
> Разделение на подсистемы сборки и дистрибуции? Так вот, последняя как раз
> и появляется. Не ущемляя первую, которая уже давно была.

Нет. Сборку я вообще не трогаю, это отдельная песня.
Высокоуровневый -- это когда одной командой
обеспечивается согласованность установленных пакетов.
К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.

Ответить | Правка | Наверх | Cообщить модератору

230. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от xxx (??), 04-Фев-12, 14:01 
>это если не считать совершенно неуместного здесь sqlite3

Это действительно не понятно. Его запихают в базовую систему?

>База -- на С, обертка -- на шеле. По-моему так правильнее.

Но есть и не менее правильная альтернатива: база на С + достаточно функциональная библиотека на С (libpkg) + обертка на чем угодно, хоть на пистоне.

Ну и 40 000 строк кода на Си не так и много.

Ответить | Правка | Наверх | Cообщить модератору

233. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от Wulf (??), 04-Фев-12, 19:32 
> Судя по ману это не столько замена pkg_install, сколько претензия на yum/apt.
> В одном флаконе так сказать.

Явно не без этого.

> если не считать совершенно неуместного здесь sqlite3

по моему мнению, как раз здесь sqlite более чем уместен. Если посмотреть
в код, авторы много SQL-ных фишек используют, отсутствующих в bdb1.85 из
libc : join-ы, выборки с регэкспами, distinct-ы, сортировки и т.д. Или
Вы считаете, что этот функционал нужно обязательно заново создавать?
solaris тоже вовсю использует sqlite для хранения внутренних баз

> Свой NIH я написал на шеле, это примерно 4000 строк, функций больше, чем в pkgng
> и pkgin (тоже для pkgsrc, но написан на С).
> Такой подход мне кажется более правильным, при условии, конечно,
> что обновление самого себя не является проблемой.
> База -- на С, обертка -- на шеле. По-моему так правильнее.

Да, так правильнее, если наблюдение NIH-а в черном окошке терминала
является основным и главным рекомендуемым способом обновления софта.
Но как только к консольной програмке захочется приделать графическую
или веб морду, вариант с большой С-библиотекой, умеющей все функции
и маленькими фронтэндами к ней, вызывающими эти функции и представляющими
их на устройство вывода в удобоваримой форме предпочтительнее.

> Высокоуровневый -- это когда одной командой
> обеспечивается согласованность установленных пакетов.
> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.

В freebsd этим традиционно занимались portupgrade и portmaster. Думаю,
нужно ждать когда в них сделают полноценную поддержку pkgng а не просто
заменят pkg_* на pkg *. В самом pkgng в этом направлении явно еще и
конь не валялся.

Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

249. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от vle (ok), 05-Фев-12, 04:36 
>по моему мнению, как раз здесь sqlite более чем уместен. Если посмотреть
>в код, авторы много SQL-ных фишек используют, отсутствующих в bdb1.85 из
>libc : join-ы, выборки с регэкспами, distinct-ы, сортировки и т.д.

Это все было бы прекрасно, если б привело к упрощению и ускорению
разработки, но пока этого не видно. Я начал писать NIH в ноябре прошлого года
и уже, в общем то, давно закончил. Код стабилен, и он работает уже сегодня,
и будет работать и дальше, никуда не денется.
pkgng же пока то ли в альфе то ли в бете.
pkgsrc-ый pkgin начал разрабатываться на год, кажется, раньше, а то и больше,
но nih уже давно предоставляет больше функций. Это не самопиар,
я говорю о выборе подходящего инструмента для данной конкретной задачи.

> Или Вы считаете, что этот функционал нужно обязательно заново создавать?

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

>solaris тоже вовсю использует sqlite для хранения внутренних баз

Да ради бога, было бы это релевантно. "Модно" -- меня не убеждает.

>> База -- на С, обертка -- на шеле. По-моему так правильнее.
> Да, так правильнее, если наблюдение NIH-а в черном окошке терминала
> является основным и главным рекомендуемым способом обновления софта.

Построение update plan для установки порядка 800 (восьмисот!!!) пакетов
с нуля на атоме-330 занимает порядка минуты. Да, это много, но вполне приемлимо
для запуска один раз за всю жизнь на "десктопе". Типичные же "тормоза"
на серверах или при апдейтах не превышают пяти секунд.
Встанет РЕАЛЬНАЯ проблема в этом месте,
перепишется один(один!) скрипт на С, но пока я проблемы здесь не вижу.

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

Ну, конкретно nih написан вполне себе в духе традиционного UNIX way,
и гуй к нему лепится на счет раз. Библиотеки здесь ни при чем.

>> Высокоуровневый -- это когда одной командой
>> обеспечивается согласованность установленных пакетов.
>> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.
> В freebsd этим традиционно занимались portupgrade и portmaster. Думаю,
> нужно ждать когда в них сделают полноценную поддержку pkgng а не просто
> заменят pkg_* на pkg *. В самом pkgng в этом направлении явно еще и
> конь не валялся.

Вот именно, "нужно ждать" и "еще конь не валялся". О чем я и говорю.

Ответить | Правка | Наверх | Cообщить модератору

267. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от wulf (ok), 05-Фев-12, 23:28 
> Это все было бы прекрасно, если б привело к упрощению и ускорению
> разработки, но пока этого не видно.

sql - язык более высокого уровня, нежели shell или C, при правильном применении
только сокращает время разработки. честно-честно.

> Я начал писать NIH в ноябре
> прошлого года
> и уже, в общем то, давно закончил. Код стабилен, и он работает
> уже сегодня,
> и будет работать и дальше, никуда не денется.
> pkgng же пока то ли в альфе то ли в бете.
> pkgsrc-ый pkgin начал разрабатываться на год, кажется, раньше, а то и больше,
> но nih уже давно предоставляет больше функций. Это не самопиар,
> я говорю о выборе подходящего инструмента для данной конкретной задачи.

pkgng - не эквивалент nih

>> Или Вы считаете, что этот функционал нужно обязательно заново создавать?
> Нет, я считаю, что данный функционал просто не нужен, ни в каком
> виде.
> Кстати, почитай ман nih на предмет возможностей поиска.

nih - обертка, а не пакетная система, как его можно сравнивать? nih
не хранит данные о установленных пакетах, ему это не надо. В отличие от...

> Нет там никакого sqlite, не нужен он там.
> Для остального -- тем более.

bdb тогда тоже не нужен. Все (почти) данные и так есть в /etc/passwd,
/etc/login.conf и т.д. Да и в линупсе/соляре без него прекрасно обходятся

>>solaris тоже вовсю использует sqlite для хранения внутренних баз
> Да ради бога, было бы это релевантно. "Модно" -- меня не убеждает.

отважусь процитировать себя: "join-ы, выборки с регэкспами, distinct-ы,
сортировки и т.д." - это все из кода pkgng. Конечно эту функциональность
можно реализовать и на shell, но "Код стабилен, и он работает уже сегодня,
и будет работать и дальше, никуда не денется" и занимает раз в 10 меньше
места (сами SQL statements, а не обертка их вызовов на C), нежели shell-ный
с теми-же функциями

> Ну, конкретно nih написан вполне себе в духе традиционного UNIX way,
> и гуй к нему лепится на счет раз. Библиотеки здесь ни при
> чем.

надеюсь, unix-way - не самоцель? Не хочу огорчать, но задача прикручивания
гуя к nih-у в процессе разработки последнего явно не ставилась. Мало того,
что с внешним миром он умеет общаться только по stdin/stdout, так и для того
чтобы получить список обновляемых пакетов надо выполнять что-то из разряда
"echo n | nih update". Разве не так?

> Вот именно, "нужно ждать" и "еще конь не валялся". О чем я
> и говорю.

Я почти не сомневаюсь, что port* быстро поправят. :)

Ответить | Правка | Наверх | Cообщить модератору

274. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от vleemail (ok), 06-Фев-12, 12:15 
>> Ну, конкретно nih написан вполне себе в духе традиционного UNIX way,
>> и гуй к нему лепится на счет раз. Библиотеки здесь ни при
>> чем.
> надеюсь, unix-way - не самоцель?

Нет. Естественный ход разработки для данной задачи.

> Не хочу огорчать, но задача прикручивания
> гуя к nih-у в процессе разработки последнего явно не ставилась. Мало того,
> что с внешним миром он умеет общаться только по stdin/stdout, так и
> для того
> чтобы получить список обновляемых пакетов надо выполнять что-то из разряда
> "echo n | nih update". Разве не так?

Нет, не так. См. pkg_update_plan.

>> Вот именно, "нужно ждать" и "еще конь не валялся". О чем я
>> и говорю.
> Я почти не сомневаюсь, что port* быстро поправят. :)

Не то, чтобы я сомневался, но посмотрим.

Ответить | Правка | Наверх | Cообщить модератору

276. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от Аноним (-), 06-Фев-12, 13:59 
> Это все было бы прекрасно, если б привело к упрощению и ускорению
> разработки, но пока этого не видно.

Учтя что они обходились без нормального пакетного манагера столько лет, довольно странно и не умно теперь пытаться сэкономить на спичках, да еще при том что пакетный манагер - штука делаемая на века. Можно конечно сэкономить несколько дней разработчику. А все остальные - помучаются с кривой какашкой пару десятилетий, да? :)

Ответить | Правка | К родителю #249 | Наверх | Cообщить модератору

282. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от kshetragia (ok), 07-Фев-12, 05:59 
>>> Никогда не понимал людей, которые пишут такие вещи на С
>> насколько я понимаю, pkgng - не надстройка, а полная замена всех pkg_*
>> утилей, причем на уровне базовой системы. На чем это может быть
>> написано кроме С - не представляю.
> Судя по ману это не столько замена pkg_install, сколько претензия на yum/apt.

Судя по ману это как раз два-в-одном. Без существенной переделки pkg_install было бы невозможно сделать подобие apt-a/yum-a/zypper-a.

> В одном флаконе так сказать.
> В pkgsrc pkg_install написан на С и кода примерно 14000 строк,
> то есть в 3 раза меньше,

  Вы внутрь заглядывали? там костыль на костыле. Вплоть до запуска утилит из под сишного кода. Очевидно писалось наспех.. Как говорится.. нет ничего более постоянного..

> это если не считать совершенно неуместного
> здесь sqlite3. Если с ним, то получается в 13(!!!) раз меньше кода.

очень даже уместного. При распухании базы хотя бы до пятисот пакетов pkg_install начинает заметно тормозить. sqlite3 мне кажется оптимальным вариантом. В 3.7 версии даже запилили WOL.

> pkgsrc-ый pkg_install -- это примерный аналог dpkg/rpm, (только лучше :-) )

Не лучше. через pkg_install невозможно обновить пакет не развалив пакетную базу. Тупо не хватает нормальных зависимостей на библиотеки/ориджины. Отсутствие инфы о том с какими KNOB-ами собран пакет. Приходилось костылить. Собсно portupgrade - попытка вылечить зубы через опу(и ему это даже удается). остальные менеджеры еще менее удачны.

> Этой базы достаточно для написания поверх нормального high-level менеджера пакетов.

Если и так всё переделывать, то какая разница. При нормальной архитектуре затраты на написание на Си менеджера-обертки примерно одинаковые по сравнению с шеллом. Если не меньше.

> Нет. Сборку я вообще не трогаю, это отдельная песня.
> Высокоуровневый -- это когда одной командой
> обеспечивается согласованность установленных пакетов.
> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.

Нет смысла. т.к. pkg_* нужно было выкинуть целиком.

Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

284. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от vleemail (ok), 07-Фев-12, 16:02 
>> В одном флаконе так сказать.
>> В pkgsrc pkg_install написан на С и кода примерно 14000 строк,
>> то есть в 3 раза меньше,
>   Вы внутрь заглядывали? там костыль на костыле. Вплоть до запуска
> утилит из под сишного кода.

Бред сивой кобылы.

> Очевидно писалось наспех.. Как говорится.. нет ничего более постоянного..

Нет.

>> это если не считать совершенно неуместного
>> здесь sqlite3. Если с ним, то получается в 13(!!!) раз меньше кода.
> очень даже уместного. При распухании базы хотя бы до пятисот пакетов pkg_install
> начинает заметно тормозить.

Нет. Не начинает.

>> pkgsrc-ый pkg_install -- это примерный аналог dpkg/rpm, (только лучше :-) )
> Не лучше. через pkg_install невозможно обновить пакет не развалив пакетную базу.

Нет. RTFM.

> Тупо не хватает нормальных зависимостей на библиотеки/ориджины. Отсутствие инфы о
> том с какими KNOB-ами собран пакет.

С чем собран пает? Какой инфы не хватает?

> Приходилось костылить. Собсно portupgrade - попытка вылечить
> зубы через опу(и ему это даже удается). остальные менеджеры еще менее
> удачны.

portupgrade к pkgsrc отношения не имеет. Иди читай документацию.

>> Этой базы достаточно для написания поверх нормального high-level менеджера пакетов.
> Если и так всё переделывать, то какая разница.

Не нужно ничего переделывать, и pkgin и nih написаны поверх pkgsrc-ного pkg_install.

> При нормальной архитектуре затраты
> на написание на Си менеджера-обертки примерно одинаковые по сравнению с шеллом.
> Если не меньше.

Нет.

>> Нет. Сборку я вообще не трогаю, это отдельная песня.
>> Высокоуровневый -- это когда одной командой
>> обеспечивается согласованность установленных пакетов.
>> К dpkg/rpm/pkg_{add,delete} это не относится, и не должно относится.
> Нет смысла. т.к. pkg_* нужно было выкинуть целиком.

Если фришники развели бардак, пусть выкидывают и переделывают.

Ответить | Правка | Наверх | Cообщить модератору

285. "Представлена первая бета-версия pkgng, нового пакетного мене..."  +/
Сообщение от kshetragia (ok), 09-Фев-12, 05:56 
>>> В pkgsrc pkg_install написан на С и кода примерно 14000 строк,
>>> то есть в 3 раза меньше,
>>   Вы внутрь заглядывали? там костыль на костыле. Вплоть до запуска
>> утилит из под сишного кода.
> Бред сивой кобылы.

Please look into the <srcdir>/usr.sbin/pkg_install/lib/
file.c:
  copy_file
  move_file
  copy_hierarchy
  unpack

pen.c:
  leave_playpen

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

>>> pkgsrc-ый pkg_install -- это примерный аналог dpkg/rpm, (только лучше :-) )
>> Не лучше. через pkg_install невозможно обновить пакет не развалив пакетную базу.
> Нет. RTFM.

Кругом смешались люди.. кони.. Тут моя ошибка. Вы всё время говорили о NetBSD-шном пакетном менеджере. Я же здесь и далее говорил о фрюшном.

> Приходилось костылить. Собсно portupgrade - попытка вылечить
> зубы через опу(и ему это даже удается). остальные менеджеры еще менее
> удачны.
> portupgrade к pkgsrc отношения не имеет.

Равно как и pkgsrc не имеет отношения к fbsd.

> Иди читай документацию.

Еще раз прошу прощения.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру