nih/pkgng

[Oleksii Tsvietnov]

Привет.

Не мог вспомнить точно на конференции, где я слышал об этой информации,
поэтому сразу не прокоментировал,
почему проект FreeBSD пока что не с nih'ом ;) Но дома нашёл ссылку:

http://wiki.freebsd.org/pkgng

Судя по git-репозиторию, проект живёт активно.
Работа ведётся, а необходимость в подобной надстройке над существующей
системой портов,
у многих давно назрела.

--
www.vorakl.name

[Andrey Fesenko]

2011/9/25 Oleksii Tsvietnov <vor...@fbsd-ng.org>:

Привет,

Да, pkgng весьма перспективен, вроде в этом году собирались обсуждать
как дальше жить с пакетами/портами, на какой то осенней европейской
BSD конференции, надо будет посмотреть, доведут ли до какого
логического завершения.

[krt3k.s]

25.09.2011 21:22, Andrey Fesenko пишет:

Всем ку.

Кто-нибудь объясните неофиту, чем плоха нынешняя система портов?

[Mykola Marzhan]

25 сентября 2011 г. 22:08 пользователь krt3k.s <krt...@gmail.com> написал:

> Кто-нибудь объясните неофиту, чем плоха нынешняя система портов?

очень-очень многим, объяснять - многа букав, осознать в душе что НАШ
подход устарел можно только уколовшись наркотиком разработки пакетов,
наркотиком резиз инженеринга в дистрибутивах линукс таких как debian и redhat.

--
Sincerely,
Mykola Marzhan

[Mykola Dzham]

2011/9/25 krt3k.s <krt...@gmail.com>

Кто-нибудь объясните неофиту, чем плоха нынешняя система портов?

Если кратко то она абсолютно не приспособлена для жизни на бинарных пакетах

--
LEFT-(UANIC|RIPE)

[Alexander Yerenkow]

2011/9/26 Mykola Dzham <mykola...@gmail.com>

2011/9/25 krt3k.s <krt...@gmail.com>

Кто-нибудь объясните неофиту, чем плоха нынешняя система портов?

Юный неофит при попытке проапгрейдить портово систему столкнётся с массовой работой обезьянки. 

При попытке бинарно систему обновить, если там накопились десятки пакетов, да ещё и какая-то крутая либа от которой много чего зависит, почти гарантированно получит нерабочую систему.

Может повезти, что ещё и иксы недообновятся, будет сидеть в консоли с почти наверняка поломанной кодировкой (если додумается запустить mc) и думать "чинить это всё, или новое что-то накатить".

Самое безобидное, это закольцованный портапгрейд/портмастер, который будет дооооолго строить дерево зависимостей, но так и не построит, потому что где-то что-то посчитает завсисимым от самого себя (ловил при обновлении КДЕ).

В общем, что-то типа того. Поставил систему - не трогай, сдувай пылинки, максимум - обнови один порт что тебе нужен :)

Это текущая религия, которая срочно требует замены.

Кстати, насчёт меток в netbsd pkg, считаю что кроме трёх меток пакета (а по сути двух, одна из которых on/off одна из которых обязательна) было бы хорошо сделать общую систему меток, как обязательных, так и не обязательных. Булевых, да и текстовых :)

Булевые облегчат работу пакет менеджерам (могут по крайней мере), а строковые помогут например юзеру ввести свои комменты к пакетам, "чтоб не забылось".

Но тут надо думать :)

Если кратко то она абсолютно не приспособлена для жизни на бинарных пакетах

--
LEFT-(UANIC|RIPE)

--
Regards,
Alexander Yerenkow

[Andrey Fesenko]

2011/9/26 Alexander Yerenkow <yere...@gmail.com>:

>
>
> Кстати, насчёт меток в netbsd pkg, считаю что кроме трёх меток пакета (а по
> сути двух, одна из которых on/off одна из которых обязательна) было бы
> хорошо сделать общую систему меток, как обязательных, так и не обязательных.
> Булевых, да и текстовых :)
> Булевые облегчат работу пакет менеджерам (могут по крайней мере), а
> строковые помогут например юзеру ввести свои комменты к пакетам, "чтоб не
> забылось".
> Но тут надо думать :)

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

А про изменение портов/пакетов, назрело давно, но вот кто бы решился :)

Про то что хороши линуксовые системы, я бы не сказал, в каждой из них
тоже полно граблей и костылей, но что нибудь полезное из них не
помешало бы. Так же были весьма любопытные мысли в опенсолярисе, так
как раз была реализована транзакционная модель установки, по крайней
мере для отдельных пакетов, но тут без ZFS не обойтись.

[Oleksii Tsvietnov]

Hi.

> О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫чёО©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ netbsd pkg, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫рёО©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
> (О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ on/off О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫)
> О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫ О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ :)

О©╫О©╫! О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ - О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ "try out", О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫
О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ 1 О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫сё О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 1 О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.

--
www.vorakl.name

[Aleksey Cheusov]

> Да! Свои метки - классная фича была бы. Ставишь пакеты со своей собственной
> меткой, а не только "try out", для одного эксперимента. Это не только 1
> пакет со своими зависимостями, которые должны паровозом удалиться при
> надобности. Это десятки пакетов, со своим десятком зависимостей. И всё это
> объединяет 1 метка, по которой потом можно удалить только помеченные ею
> пакеты.

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

P.S.
Но вы все-таки подумайте, может имеет смысл взяться за pkgsrc?
Не вместо, а в дополнение к ;-)

[Aleksey Cheusov]

2011/9/26 Alexander Yerenkow <yere...@gmail.com>:

> Кстати, насчёт меток в netbsd pkg, считаю что кроме трёх меток пакета (а по
> сути двух, одна из которых on/off одна из которых обязательна) было бы
> хорошо сделать общую систему меток, как обязательных, так и не обязательных.
> Булевых, да и текстовых :)
> Булевые облегчат работу пакет менеджерам (могут по крайней мере), а
> строковые помогут например юзеру ввести свои комменты к пакетам, "чтоб не
> забылось".
> Но тут надо думать :)

У меня в планах сделать еще одну метку -- hold. Она будет обозначать
"пакет не обновлять и не удалять ни в коем случае!".
Это аналог аналогичного маркера в Debian.
Опять же, это делается поверх существующего формата pkgdb и команды pkg_admin.

Если есть другие соображения, дайте знать ;-)
Мне пока не придумывается.

Что до pkgng -- не проще ли пофиксить pkg_*?
Впрочем, дело ваше.

[Mykola Dzham]

2011/9/27 Aleksey Cheusov <a.ch...@gmail.com>

P.S.
Но вы все-таки подумайте, может имеет смысл взяться за pkgsrc?
Не вместо, а в дополнение к ;-)

Та уже в процессе ковыряния.

--
LEFT-(UANIC|RIPE)

[Aleksey Cheusov]

> Вот насчет меток, я тоже так сразу подумал, что однозначно нужно какое
> то подмножество текстовых, но потом что то забыл попытать Алексея,

you are welcome ;-)

> но как я понял пока это просто опирается на уже существующую
> инфраструктуру и там этого нет.

Инфраструктура как раз есть.

work# pkg_admin set fun='NIH rocks!' emacs
work# pkg_bin_summary -f PKGNAME,fun emacs
PKGNAME=emacs-22.3nb14
fun=NIH rocks!

work# pkg_bin_summary -f PKGNAME,fun mrxvt
PKGNAME=mrxvt-0.5.4nb5

work# pkg_admin unset fun emacs
work# pkg_bin_summary -f PKGNAME,fun emacs
PKGNAME=emacs-22.3nb14

work#

> Про то что хороши линуксовые системы, я бы не сказал, в каждой из них
> тоже полно граблей и костылей, но что нибудь полезное из них не
> помешало бы.

На мой взгляд rpm/dpkg хвастаться абсолютно нечем перед pkgsrc-шными
pkg_{add,delete,admin,info}.

apt/yum/zypper: единственная на мой взгляд достойная фича -- это
поддержка установки их множества различных репозиториев. Остальное --
ничего особенного. Множественности реп в ближайшие годы pkgsrc не
грозит, поэтому в NIH-е этого нет.

А то, что rpm как менеджит пакеты, так и собирает их -- это вообще
ошибка ДНК. Уж эти то вещи можно было бы разделить!

[Aleksey Cheusov]

2011/9/27 Mykola Dzham <mykola...@gmail.com>:

> 2011/9/27 Aleksey Cheusov <a.ch...@gmail.com>
>>
>> P.S.
>> Но вы все-таки подумайте, может имеет смысл взяться за pkgsrc?
>> Не вместо, а в дополнение к ;-)
>
> Та уже в процессе ковыряния

Для ковыряния и игр не с самого начала я, в принципе, могу выложить
куда-нибудь построенные мной пакеты для 8.0/x86_64, если у кого есть
желание. Они где-то за май. Для масштабных и не очень сборок можно
использовать мой pkgtools/distbb или pkgtools/pbulk (официальный тул by
joerg@). Результаты работы distbb для FreeBSD можно глянуть здесь

http://mova.org/~cheusov/pub/pkgsrc-distbb/FreeBSD/logs/20110511.1247/META/report.html

Все как есть, без прикрас. Единственное что, включены параноидальные
проверки (PKG_DEVELOPER=yes), из-за чего многие пакеты фейлят на стадии
Package, например (PLIST check).

Альтернатива pkgtools/nih -- pkgtools/pkgin.

Кстати, сейчас активно пилится поддержка clang,
в смысле чинятся пакеты.
Результаты балкбилдов с clang ищите здесь

http://mail-index.netbsd.org/pkgsrc-bulk/tindex.html