форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
Сообщение от opennews (ok) on 01-Янв-11, 22:44
Алексей Чеусов (http://www.mova.org/~cheusov/)  в списке рассылки разработчиков NetBSD представил (http://mail-index.netbsd.org/pkgsrc-users/2010/12/29/msg0134...) экспериментальный пакетный менеджер nih (https://github.com/cheusov/pkgnih), работающий в виде надстройки над системой pkgsrc (http://www.netbsd.org/docs/software/packages.html). Пакетный менеджер nih (wip (http://pkgsrc-wip.sourceforge.net/)/pkgnih-current (http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/.../)) заменяет собой существующие утилиты pkg_comp, pkg_chk и pkg_rr, преследуя цель упрощения выполнения операций по обновлению бинарных пакетов и выполняя функции сходные с такими пакетными менеджерами, как apt, yum и zypper. Код проекта написан на shell и awk. В будущем, помимо реализованных функций для работы с бинарными пакетами, планируется добавить поддержку выполнения обновлений на базе исходных текстов, задействовав программу wip/distbb для сборки пакета в изолированном окружении. ... URL: http://mail-index.netbsd.org/pkgsrc-users/2010/12/29/msg0134... Новость: http://www.opennet.me/opennews/art.shtml?num=29176
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

3. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+4 +/–
Сообщение от skybon (ok) on 01-Янв-11, 22:49
>Nih вначале загружает все необходимые файлы, а уже потом начинает процесс обновления Охренеть достижение.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+3 +/–
	Сообщение от Аноним (??) on 01-Янв-11, 23:26
	Достижение, с учетом того, что pkgsrc, pkg_install, pkg_add и порты во FreeBSD пошагово качают и стаявт один пакет за другим, так что если один пакет не скачался или не скомпилился, разорвав цепочку установки посередине, можно влипнуть в неприятную ситуацию.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	8. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от Aquarius (ok) on 02-Янв-11, 02:17
	> Достижение, с учетом того, что pkgsrc, pkg_install, pkg_add и порты во FreeBSD > пошагово качают и стаявт один пакет за другим, так что если > один пакет не скачался или не скомпилился, разорвав цепочку установки посередине, > можно влипнуть в неприятную ситуацию. речь идет о pkgsrc из NetBSD, аналоге ports из FreeBSD
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	16. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от cvsup (ok) on 02-Янв-11, 18:52
	> и порты во FreeBSD пошагово качают и стаявт один пакет за другим, make fetch-recursive
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	28. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от тигар (ok) on 03-Янв-11, 10:10
	рекомендую. s/fetch/checksum/ либо portmaster/portupgrade -aF для уже установленного ПО
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	31. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от DeadLoco (ok) on 03-Янв-11, 12:31
	"..если один пакет не скачался или не скомпилился, разорвав цепочку установки посередине, можно влипнуть в неприятную ситуацию.." Эх, сколько их было, таких случаев. ИЧСХ, ни разу никаких фатальных последствий. Самое неприятное - придется заново запустить "portmaster -btw -Da". Если сильно боязно, что какие-нибудь сырцы не докачаются, можно прогнать в два приема, с ключиком -n и без него.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	58. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Аноним (??) on 05-Янв-11, 20:51
	вы вероятно не знаете команду "make fetch-recursive"
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	72. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от dukzcry on 21-Дек-11, 23:13
	Я немного не в тему, но вопрос к знатокам системы pkgsrc: при сборке пакета, можно ли заставить автоматически скачивать и ставить бинарные пакеты его зависимостей, вместо их сборки? В системе OpenBSD ports существует переменная окружения FETCH_PACKAGES (прописываемая в /etc/mk.conf), выставив которой значение Yes, можно добиться того, о чем я спрашиваю (см. http://www.openbsd.org/cgi-bin/man.cgi?query=ports&sektion=7... C-f FETCH_PACKAGES). Подытожим: У pkgsrc есть аналог FETCH_PACKAGES?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	74. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от dukzcry on 09-Фев-12, 18:42
	Вопрос снят, спасибо Алексею. Вот солюшн: http://www.netbsd.org/docs/pkgsrc/using.html#how-to-build-an... . См. предпоследний абзац секции.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

4. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
Сообщение от Michael Shigorin (ok) on 01-Янв-11, 22:52
И вот пусть теперь Лёша только заикнётся про NIH-синдром! :))
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от vle (ok) on 02-Янв-11, 20:53
	Да это, как я понимаю, Игорь Чубин решил меня попиарить. Так что это не я. А что до nih, то им, Миша, болеют не только альтовцы ;-) И у меня есть грешок. Чем мне угодили pkgin, pkg_comp, pkg_chk и прочие могу, конечно, и объяснить, но тебе это вряд ли будет интересно. Тебе же это все равно не интересно, на поиск, который лучше чем у вас, я уже показывал.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	18. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Michael Shigorin (ok) on 02-Янв-11, 21:13
	> А что до nih, то им, Миша, болеют не только альтовцы ;-) Только у нас со всех больших всё ж! ;-)  Но причина, как понимаю, схожая -- "ну нельзя же так". > Чем мне угодили pkgin, pkg_comp, pkg_chk и прочие > могу, конечно, и объяснить, но тебе это вряд ли будет интересно. Ну почему, не исключено.  Хотя это если не влом. > на поиск, который лучше чем у вас, я уже показывал. Да и я тебе, помнится, показывал, куда пар направился.  А околопакетовидной частью у нас icesik@ потихоньку занимается вот здесь: http://prometheus.altlinux.org (хотя до именно той части, на которую ты обращал внимание, руки ещё ни у кого толком не доходили).
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	20. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от vle (ok) on 02-Янв-11, 22:37
	>> А что до nih, то им, Миша, болеют не только альтовцы ;-) > Только у нас со всех больших всё ж! ;-)  Но причина, > как понимаю, схожая -- "ну нельзя же так". В точку! >> Чем мне угодили pkgin, pkg_comp, pkg_chk и прочие >> могу, конечно, и объяснить, но тебе это вряд ли будет интересно. > Ну почему, не исключено.  Хотя это если не влом. Ээээ, скорее в лом. Для крсткости обойдемся твоей форомулировкой "ну нельзя же так". Я пока в поезде. Домой приеду, посмотрим. >> на поиск, который лучше чем у вас, я уже показывал. > Да и я тебе, помнится, показывал, куда пар направился. Пардон? > А околопакетовидной > частью у нас icesik@ потихоньку занимается вот здесь: http://prometheus.altlinux.org > (хотя до именно той части, на которую ты обращал внимание, руки > ещё ни у кого толком не доходили). Да этим не у вас надо заниматься, а в апстриме. Кто там сейчас apt-get-ом занимается? Ну а yum/zypper-ом пусть RedHat/SuSE доделывают. Я предела своих мечтаний почти достиг :-)
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	23. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от JL2001 (ok) on 03-Янв-11, 01:00
	>>> на поиск, который лучше чем у вас, я уже показывал. >> Да и я тебе, помнится, показывал, куда пар направился. >> А околопакетовидной >> частью у нас icesik@ потихоньку занимается вот здесь: http://prometheus.altlinux.org >> (хотя до именно той части, на которую ты обращал внимание, руки >> ещё ни у кого толком не доходили). > Да этим не у вас надо заниматься, а в апстриме. Кто там > сейчас apt-get-ом > занимается? Ну а yum/zypper-ом пусть RedHat/SuSE доделывают. > Я предела своих мечтаний почти достиг :-) можно тезисно чего не хватает apt-get-у ? (ну и yum/zypper тот же вопрос)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	26. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+2 +/–
	Сообщение от vle (ok) on 03-Янв-11, 01:25
	>[оверквотинг удален] >>> А околопакетовидной >>> частью у нас icesik@ потихоньку занимается вот здесь: http://prometheus.altlinux.org >>> (хотя до именно той части, на которую ты обращал внимание, руки >>> ещё ни у кого толком не доходили). >> Да этим не у вас надо заниматься, а в апстриме. Кто там >> сейчас apt-get-ом >> занимается? Ну а yum/zypper-ом пусть RedHat/SuSE доделывают. >> Я предела своих мечтаний почти достиг :-) > можно тезисно чего не хватает apt-get-у ? (ну и yum/zypper тот же > вопрос) Прежде всего нормального поиска. При количестве пакетов, давно перевалившим за 20000 поиск остается убогим во всех выше перечисленных системах. В nih он на мой взгляд лучше, значительно меньше нерелевантного мусора. Собственно встроено вот это http://mail-index.netbsd.org/pkgsrc-users/2010/11/23/msg0132... То есть, здесь мы имеем поиск различными стратегиями поиска по разным полям и их комбинации. При этом выбран хороший дефолт. Кроме того, в nih есть поиск в удаленной базе через посредством dict protocol-а, вот так http://mail-index.netbsd.org/pkgsrc-users/2008/02/02/msg0002... только другой командой "nih search -o". Ну и кроме того, "nih install" умеет принимать не только пакеты для установки и обновления, но и для удаления, т.е. одновременно, что позволяет не обновляться в два этапа: вначале сносим пол системы, а потом ставим все обратно, но с другими зависимостями/альтернативами, а за один заход. Но это нужно довольно редко, хотя иногда позволяет сильно уменьшить количество потраченных нервов при работе с backports и подобными. Насчет остального я как-то не сильно задумывался, если честно. А, вот еще, pkg из OpenIndiana просто безбожно тормозит, я ума не приложу, чем можно заниматься СТОЛЬКО времени, вычисляя update plan.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	36. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	–1 +/–
	Сообщение от Michael Shigorin (ok) on 03-Янв-11, 15:12
	> поиск остается убогим во всех выше перечисленных системах. В nih Ты точно читал http://lwn.net/Articles/415168/? > Собственно встроено вот это > http://mail-index.netbsd.org/pkgsrc-users/2010/11/23/msg0132... По сравнению с xapian (который я тоже давно люблю и всё собираюсь поприкручивать не только к своей почте) это всё поделки, сам понимаешь.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	42. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от vle (ok) on 03-Янв-11, 18:39
	>> поиск остается убогим во всех выше перечисленных системах. В nih > Ты точно читал http://lwn.net/Articles/415168/? Поиск по тегам. Ну и что? Это всего лишь еще одно поле для поиска. pkg_digger/pkg_online_find и там искать будут если на вход эти теги поступят. >> Собственно встроено вот это >> http://mail-index.netbsd.org/pkgsrc-users/2010/11/23/msg0132... > По сравнению с xapian это всё поделки, сам понимаешь. Я понял. Ты уже НИКОГДА не научишься читать документацию. Типичный малограмотный альтовец, и на этот раз я не стану просить прощения.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	49. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Michael Shigorin (ok) on 04-Янв-11, 16:46
	> pkg_digger/pkg_online_find и там искать будут если на вход > эти теги поступят. 1) *если*; 2) не я ж стал заикаться (точнее, кидать пальцы) про sane defaults, а? ;-) >> По сравнению с xapian это всё поделки, сам понимаешь. > Я понял. Ты уже НИКОГДА не научишься читать документацию. Лёш, я как бы некоторое время потратил на раскапывание вопросов в т.ч. faceted search, да и некоторый практический опыт с разными индексаторами (разумеется, с прочтением документации) тоже имеется за последние лет двенадцать.  Достаточно большую систему управления мобильным контентом сархитектурил тоже уже давно, там как раз категоризация была ключом (предшественники упёрлись носом в транспорт). Ты, как нередко, ничего не понял, зато занервничал на пустом месте -- как только тебя ткнули носом (грубовато, но по-дружески, между прочим) во что-нибудь действительно стоящее и давно существующее. Разумеется, проще всего сказать "да ты лох" и не думать о том, что в других мы прежде всего склонны видеть отражение себя ;-) PS: про axi-cache почитай ещё, Колумб. :)
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	50. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от vle (ok) on 04-Янв-11, 17:24
	>> pkg_digger/pkg_online_find и там искать будут если на вход >> эти теги поступят. > 1) *если* Это уже не ко мне. Будут теги -- будет по ним поиск. Мне все равно, откуда они возьмутся, и возьмутся ли. Это во-первых. Во-вторых, тебе продемонстировать, как pkg_digger и pkg_online_find может работать под Debian и AltLinux с тегами и без них? Уж всяко лучше альтовского apt-cache-а. Я ведь не поленюсь, и тебе будет стыдно. > 2) не я ж стал заикаться (точнее, кидать пальцы) про sane defaults, > а? ;-) Как работает apt-cache в AltLinux-е можешь мне даже не показывать, я знаю. То, что ниже -- good enough без всякого тайного знания о тегах и нескольких человеколет потраченного труда. Сделанное мной -- сделано за несколько вечеров. Впрочем, простоту решения ты все равно не поймешь. О дефолтах. 0 cheusov>nih search -o dns server                                                       net/dhisd                 -   DynDNS server net/fpdns                 -   Fingerprinting DNS servers net/maradns               -   Secure DNS server for *NIX systems net/mydns-mysql           -   MySQL-based DNS server net/mydns-pgsql           -   PostgreSQL-based DNS server net/nsd                   -   Authoritative-only DNS server net/p5-Net-DNSServer      -   Perl5 module to be used as a domain name server net/powerdns              -   Modern, advanced and high performance nameserver net/powerdns-recursor(pdns-recursor) -   PowerDNS resolver/recursing nameserver net/rootprobe             -   Root DNS server performance analysis net/unbound               -   DNS resolver and recursive server sysutils/wbm-bind8        -   Webmin module for managing ISC BIND 8.x DNS servers wip/ldapdns(ldapdns-cvs)  -   Tiny, fast authoritative nameserver that queries LDAP wip/py-oak(py24-oak)      -   Authoritative/recursive DNS server wip/py-oak(py25-oak)      -   Authoritative/recursive DNS server wip/py-oak(py26-oak)      -   Authoritative/recursive DNS server 0 cheusov>nih search -o web browser                                                       chat/cgiirc               -   Access IRC from a web browser devel/global              -   Source code tag system including web browser output mail/claws-mail-dillo-viewer -   Plugin to use the Dillo web browser for html rendering wip/arora                 -   Arora is a web browser using Qt and Webkit wip/elinks-snapshot(elinks-snap) -   Extended/Enhanced links text-mode web browser (snapshot) wip/firefox               -   Web browser with support for extensions wip/surf                  -   Surf is a fast and minimalistic web browser based on WebKit/GTK+ www/amaya                 -   Web browser/editor from the World Wide Web Consortium (W3C) www/browser-bookmarks-menu -   Easy access to web bookmarks through a GNOME Panel Applet www/chimera               -   World Wide Web Browser for X Windows www/dillo                 -   Very small and fast graphical web-browser www/epiphany              -   The web browser for the GNOME Desktop www/epiphany-extensions   -   Extensions for the Epiphany web browser www/firefox               -   Web browser with support for extensions www/firefox-bin           -   Lightweight gecko-based web browser (binary package) www/kazehakase            -   Web browser with multiple layout engines support www/midori                -   Lightweight web browser using WebKit www/netsurf               -   Web browser for RISC OS and UNIX-like platforms www/p5-HTML-Clean         -   Perl5 module that cleans up HTML code for web browsers www/p5-SVN-Web            -   Unstable snapshot of Subversion repository browser www/viewvc                -   Viewing the content of CVS/SVN repositories with a Webbrowser www/w3                    -   World Wide Web browser for Emacs www/wApua                 -   Web browser for WAP WML www/webkit-gtk            -   GTK2 port of the WebKit browser engine 0 cheusov> >>> По сравнению с xapian это всё поделки, сам понимаешь. >> Я понял. Ты уже НИКОГДА не научишься читать документацию. > Лёш, я как бы некоторое время потратил на раскапывание вопросов в т.ч. Ты способен понять, что такое ПОЛЕ ПОИСКА и СТРАТЕГИЯ ПОИСКА, и то, что они определяются сменным бэкендом? pkg_digger_backend ищет простым сканом текстового файла, и этого достаточно для поиска в пакетах. pkg_online_client -- ищет через dict protocol, обращаясь к серверу. > как только тебя ткнули носом (грубовато, но по-дружески, между прочим) во > что-нибудь действительно стоящее и давно существующее. Не смеши мои тапки, тыкатель :-) Про debtags и про поиск по ним я знаю с тех пор, как они появились, т.е. уже не один год. > Разумеется, проще всего сказать "да ты лох" и не думать о том, > что в других мы прежде всего склонны видеть отражение себя ;-) Ути пути. Тыкатель мне нашелся :-) Иди работай! > PS: про axi-cache почитай ещё, Колумб. :) Ага, ты мне еще про полнотекстовые поисковики раскажи :-) Иди ка ты лучше улучшай свой altlinux, займись делом. Впрочем, можешь про комисарова еще что-нибудь на заборе написать, это веселее.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	51. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Michael Shigorin (ok) on 04-Янв-11, 18:54
	>> 1) *если* > Это уже не ко мне. Будут теги -- будет по ним поиск. Ну вот, как только сложное -- "не ко мне"... > Я ведь не поленюсь, и тебе будет стыдно. Это займёт у тебя некоторое время на одноразовые подпорки (втягивание метаданных), а собственно инфраструктура тебе ж неинтересна.  Зачем городить потёмкинские деревни, тут лучше поленись. :) >> 2) не я ж стал заикаться (точнее, кидать пальцы) про sane defaults, а? ;-) > Как работает apt-cache в AltLinux-е можешь мне даже не показывать, я знаю. Регэксы по summary+description, что там показывать. > То, что ниже -- good enough без всякого тайного знания о тегах > и нескольких человеколет потраченного труда. И тем не менее ты опираешься на готовые метаданные в описаниях.  Но они тебе неинтересны. Понятно, что одно дело -- инструмент, а другое -- к чему его применять, но для осмысленного результата нужны обе части вопроса, и это важно.  То есть недостаточно бросить в морду шикарную тулзу или же базу дескрипшенов.  Надо вместе работать.  А это сложно, нудно и неинтересно. > Сделанное мной -- сделано за несколько вечеров. > Впрочем, простоту решения ты все равно не поймешь. Да ладно тебе, я порой могу оценить изящное.  Вон /etc/control.d/functions, например. > О дефолтах. 1) "-o" кривовато выглядит, если уж совсем о дефолтно-минимальном случае и докапываться; 2) это пример на качество метаданных в первую очередь. > Ты способен понять, что такое ПОЛЕ ПОИСКА и СТРАТЕГИЯ ПОИСКА, > и то, что они определяются сменным бэкендом? Каэшшно. > pkg_digger_backend ищет простым сканом текстового файла, > и этого достаточно для поиска в пакетах. Заодно это так себе масштабируется (про 20K пакетов тоже не я упоминал) и малопригодно для использования, скажем, на публичном сайте с информацией о репозиториях. На localhost, видимо, достаточно -- я тоже порой грепаю base/contents_index и ленюсь нарисовать что-нить индексированное, потому как устраивает.  А вот веб-морду к такому прикрутить уже боязно. > pkg_online_client -- ищет через dict protocol, обращаясь к серверу. Это тоже заценил -- "пакетно-английский словарь" :) > Не смеши мои тапки, тыкатель :-) Про debtags и про поиск по > ним я знаю с тех пор, как они появились, т.е. уже не один год. Ура :-) > Иди работай! Совесть имей, я и так вчера перелопатил конторский интранет, пока народ отдыхает :-) >> PS: про axi-cache почитай ещё, Колумб. :) > Ага, ты мне еще про полнотекстовые поисковики раскажи :-) (озираясь) Лёш, они повсюду! :-) > Иди ка ты лучше улучшай свой altlinux, займись делом. Так я потихоньку и пилю те самые mkimage-profiles.git, что и с тобой обсуждали. > Впрочем, можешь про комисарова еще что-нибудь на заборе написать, > это веселее. Да грустно это, на самом-то деле.  Может, мог бы чего полезного сделать, где умеет.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	52. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от vle (ok) on 04-Янв-11, 19:16
	>>> 1) *если* >> Это уже не ко мне. Будут теги -- будет по ним поиск. > Ну вот, как только сложное -- "не ко мне"... Не вижу здесь ничего сложного. Когда/если в pkgsrc появятся теги, тогда будет по ним поиск. Пока есть только категории, их 52. Технических проблем с добавлением тегов опять же никаких. Формат бинаря и дерева pkgsrc их позволяет реализовать за пол часа. >> Я ведь не поленюсь, и тебе будет стыдно. > Это займёт у тебя некоторое время на одноразовые подпорки (втягивание метаданных), а > собственно инфраструктура тебе ж неинтересна.  Зачем городить потёмкинские деревни, тут > лучше поленись. :) Я вас умоляю. Метаданные... Всего лишь нужно сконвертировать дебиноидный rfc822 в формат pkg_summary(5) из pkgsrc и "свести задачу к предыдущей". У меня это уже в планах года два, все лень. >>> 2) не я ж стал заикаться (точнее, кидать пальцы) про sane defaults, а? ;-) >> Как работает apt-cache в AltLinux-е можешь мне даже не показывать, я знаю. > Регэксы по summary+description, что там показывать. Мдэ, купи себе букварь, там много буков. >> То, что ниже -- good enough без всякого тайного знания о тегах >> и нескольких человеколет потраченного труда. > И тем не менее ты опираешься на готовые метаданные в описаниях.   > Но они тебе неинтересны. Чего? > Понятно, что одно дело -- инструмент, а другое -- к чему его > применять, но для осмысленного результата нужны обе части вопроса, и это > важно.  То есть недостаточно бросить в морду шикарную тулзу или > же базу дескрипшенов.  Надо вместе работать.  А это сложно, > нудно и неинтересно. Много слов ни о чем. Есть инструмент, универсальный. Будут теги -- будет по ним поиск. Ни единой строки кода добавлять не нужно. >> О дефолтах. > 1) "-o" кривовато выглядит, если уж совсем о дефолтно-минимальном случае и докапываться; -o -- это поиск в online базе, без нее будет искать offline. > 2) это пример на качество метаданных в первую очередь. Не только. Это пример неплохо выбранного дефолта. Кстати, юзверь может их менять, как ему вздумается. >> pkg_digger_backend ищет простым сканом текстового файла, >> и этого достаточно для поиска в пакетах. > Заодно это так себе масштабируется (про 20K пакетов тоже не я упоминал) > и малопригодно для использования, скажем, на публичном сайте с информацией о > репозиториях. В pkgsrc >9000 пакетов. На Athom-330 1.6 Ghz прекрасно работает. Задержка минимальна в несколько секунд. Вспоминаем про бекенд, появится *реальная* проблема -- появится решение с базой данных, cdb, bdb, sqlite -- че там сейчас модно. >> pkg_online_client -- ищет через dict protocol, обращаясь к серверу. > Это тоже заценил -- "пакетно-английский словарь" :) Ты RFC2229 читал? >>> PS: про axi-cache почитай ещё, Колумб. :) >> Ага, ты мне еще про полнотекстовые поисковики раскажи :-) > (озираясь) Лёш, они повсюду! :-) Открытие! >> Иди ка ты лучше улучшай свой altlinux, займись делом. > Так я потихоньку и пилю те самые mkimage-profiles.git, что и с тобой > обсуждали. Ну вот и я пилю.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	29. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Michael Shigorin (ok) on 03-Янв-11, 11:44
	> Я пока в поезде. Домой приеду, посмотрим. Доброго пути! >>> на поиск, который лучше чем у вас, я уже показывал. >> Да и я тебе, помнится, показывал, куда пар направился. > Пардон? В qa-robot, repocop, girar-builder -- сборку и QA. >> А околопакетовидной частью [...] http://prometheus.altlinux.org > Да этим не у вас надо заниматься, а в апстриме. Не apt имел в виду, а предоставление информации о репозиториях.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

6. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
Сообщение от Анон on 01-Янв-11, 23:40
То, что уже много лет доступно в Линуксе наконец-то добралось до БСД. В другие БСДы портируют?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от Aquarius (ok) on 01-Янв-11, 23:59
	pkgsrc с одной стороны, очень похожа на порты (ports) FreeBSD, с другой, имеет существенные различия к примеру, зависимости и конфликты в pkgsrc могут (и обычно так и есть) быть указаны в виде неравенства, в портах же только в виде <категория>/<порт>, что может сильно осложнить портирование на FreeBSD для использования с родными портами (система pkgsrc может быть использована на достаточно широком спектре операционных систем) про порты (ports) OpenBSD сказать ничего не могу
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	12. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Анон on 02-Янв-11, 09:57
	Вообще, pkgsrc портирована на множество unix-like систем. Английская википедия говорит, что 15. Это почти все опенсорсные юникс-подобные. Затея благородная, если их объединит удобный пакетный менеджмент, то различия невелируются и проблем в администрировании будет меньше.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	13. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от жопка on 02-Янв-11, 16:15
	Да ладно, во фряшных портах очень легко указывать зависимости от другого по в различных стадиях (компиляция, линковка, рантайм-библиотеки). Причем для каждой из зависимостей можно указывать необходимые версии.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	22. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Aquarius (ok) on 02-Янв-11, 23:26
	> Да ладно, во фряшных портах очень легко указывать зависимости от другого по > в различных стадиях (компиляция, линковка, рантайм-библиотеки). Причем для каждой из зависимостей > можно указывать необходимые версии. а версию, кроме как именем порта как-нибудь можно указать? (я знаю, о чем я говорю)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	30. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от жопка on 03-Янв-11, 12:11
	Да, конечно: http://www.freebsd.org/doc/en/books/porters-handbook/makefil...
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	47. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Gr on 04-Янв-11, 04:00
	То что уже много лет ставит устаревшие пакеты в линуксе ни когда до бсд не доберется. Тут речь о сборке.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	–1 +/–
Сообщение от Аноним (??) on 02-Янв-11, 03:42
Зачем ее портировать на FreeBSD - там порты. А nih - это недопиленный (пока) portmaster, я так понимаю.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Aquarius (ok) on 02-Янв-11, 05:26
	> Зачем ее портировать на FreeBSD - там порты. А nih - это > недопиленный (пока) portmaster, я так понимаю. затем же, зачем было писать для NetBSD (pkgsrc гибче ports)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от жопка on 02-Янв-11, 16:16
	> затем же, зачем было писать для NetBSD (pkgsrc гибче ports) Чем pkgsrc в NetBSD гибче FreeBSD ports?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	19. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+2 +/–
	Сообщение от vle (ok) on 02-Янв-11, 22:30
	>> затем же, зачем было писать для NetBSD (pkgsrc гибче ports) > Чем pkgsrc в NetBSD гибче FreeBSD ports? Я небольшой спец по фришным портам, но насколько я знаю, там нет аналога pkgsrc-оного pkg_add -A, устанавливающая пакет как зависимость. и соответственно возможности удалить автоматически "повисшие" листовые пакеты. Совершенно фундаментальная и очень простая вещь, и во фре этого нет. Буду рад ошибиться. Ну а основное достоинство pkgsrc -- это, конечно же, портабельность. pkgsrc работают на всем, что только движется. Это основная система не только на NetBSD, но и на DragonFlyBSD. Буквально на днях от MirBSD пришла инициатива портировать pkgsrc и на их систему, ибо нет сил (так и написали) поддерживать свои порты. Там реально полтора человека, но тем не менее. pkgsrc портировали на Minix, есть люди, которые его там пилят и делабт бинарные репо. То же касается QNX. Ну и прочие. У меня помимо NetBSD работает на CentOS, Debian и OpenSolaris.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	25. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от ABC (??) on 03-Янв-11, 01:18
	>во фре этого нет. >Буду рад ошибиться. Начинайте радоваться :) Во Фре есть несколько способов удалить автоматически "повисшие" листовые пакеты. Фокус в том, что утилиты pkg_* не придназначены для охвата всех возможных вариантов использования - это только базис, поверх которого существуют portmaster, portupgrade и еще несколько более специфических инструментов.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	27. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от vle (ok) on 03-Янв-11, 01:29
	>>во фре этого нет. >>Буду рад ошибиться. > Начинайте радоваться :) > Во Фре есть несколько способов удалить автоматически "повисшие" листовые пакеты. Фокус > в том, что утилиты pkg_* не придназначены для охвата всех возможных Не, про pkg_leaves я в курсе, такое же есть и в pkgsrc. Но я не смотел в исходники и не в курсе, как оно работает. В pkgsrc этот флажек вбит прямо в pkg_add и соответственно в pkg_delete, т.е. в pkgdb. Это IMHO базовый уровень, ясно, что внешние утилиты могут хранить дополнительные потроха где угодно, и сами же этими потрохами могут и воспользоваться.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	32. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от DeadLoco (ok) on 03-Янв-11, 13:18
	> В pkgsrc этот флажек вбит прямо в pkg_add и соответственно в pkg_delete, > т.е. в pkgdb. > Это IMHO базовый уровень, ясно, что внешние утилиты могут хранить дополнительные потроха > где угодно, и сами же этими потрохами могут и воспользоваться. А что в этом хорошего? Каноничный unix-way предполагает атомарность функционала. Всякая низкоуровневая тулза должна выполнять одну функцию, но зато хорошо. Зачем впихивать невпихуемое? Пусть даже впихуемое - зачем?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	33. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от JL2001 (ok) on 03-Янв-11, 14:20
	>> В pkgsrc этот флажек вбит прямо в pkg_add и соответственно в pkg_delete, >> т.е. в pkgdb. >> Это IMHO базовый уровень, ясно, что внешние утилиты могут хранить дополнительные потроха >> где угодно, и сами же этими потрохами могут и воспользоваться. > А что в этом хорошего? Каноничный unix-way предполагает атомарность функционала. Всякая > низкоуровневая тулза должна выполнять одну функцию, но зато хорошо. Зачем впихивать > невпихуемое? Пусть даже впихуемое - зачем? затем что в dpkg не было флагов "автоматически установлен" и нет до сих пор + нет всяких "автоматически установлен по рекомендации" и в результате apt-get, aptitude и 3 менеджер (забыл название) реализовывали эти флаги самостоятельно и приходилось использовать 4 тулзу которая синхронизировала базы первых 3х по флагам "автоматически установлено" ==> dpkg не давало необходимой атомарной функциональности и требовало создание велосипедов которые на высшем уровне пытались покрыть недосдачу
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	34. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от DeadLoco (ok) on 03-Янв-11, 14:34
	> затем что в dpkg не было флагов "автоматически установлен" и нет до сих пор > + нет всяких "автоматически установлен по рекомендации" А в чем разница между "автоматически установлен" и просто "установлен"? Есть флаг REQUIRED_BY и депенденсы - разве их недостаточно для проверки связности графа?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	35. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от JL2001 (ok) on 03-Янв-11, 15:11
	>> затем что в dpkg не было флагов "автоматически установлен" и нет до сих пор >> + нет всяких "автоматически установлен по рекомендации" > А в чем разница между "автоматически установлен" и просто "установлен"? > Есть флаг REQUIRED_BY и депенденсы - разве их недостаточно для проверки связности > графа? ок 1) кому требуется установленный пакет quake3 ? никому ==> мы его удаляем ? 2) кому требуется установленный пакет quake3 ? установленному пакету quake3-editor мы удаляем пакет quake3-editor, удалять ли пакет quake3 ? 3) кому требуется установленный пакет quake3-lib ? установленному пакету quake3 мы удаляем пакет quake3, удалять ли пакет quake3-lib ?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	37. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от DeadLoco (ok) on 03-Янв-11, 15:57
	> 1) кому требуется установленный пакет quake3 ? никому ==> мы его удаляем? > 2) кому требуется установленный пакет quake3 ? установленному пакету quake3-editor > мы удаляем пакет quake3-editor, удалять ли пакет quake3 ? > 3) кому требуется установленный пакет quake3-lib ? установленному пакету quake3 > мы удаляем пакет quake3, удалять ли пакет quake3-lib ? 1. Нет 2. Нет 3. Нет Удаление порта - листового ли, узлового ли, НЕ ДОЛЖНО вызывать никаких действий, кроме удаления самого порта. А затем пользователь должен решить, какую из процедур ему запустить: - замещение удаленного порта новым (portmaster -o games/quake3 games/quake3.1 && portmaster -r quake3.1) - рекурсивное удаление оборваной (stale) ветви (portmaster -s) Вероятность отказа системы пропорциональна квадрату ее сложности, и единственное известное лекарство - функциональная декомпозиция. Ака unix-way. Меня настораживают решения "все в одном", потому что вероятность глюка этого "одного" горадо выше, чем глюка утилей, реализующих атомарный функционал. Я предпочту вылизанные до блеска пкж_*, которые делают то, и только то, что написано - адд, делит, инфо етц - и врапперы поверх них, вроде портмастера/портапгрейда/портманагера. Уже только потому, что в случае косяка во враппере я могу вручную выполнить все процедуры через пкж_*. Да, это трудоемко, но это возможно. А если накосячит писатель пкжсрц, который скрестил ужа с ежом, мне придется тупо куковать, пока он не отчехлится. Без альтернативы. Поэтому мне идея функциональной аггрегации неприятна и подозрительна. Я за декомпозицию.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	38. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Michael Shigorin (ok) on 03-Янв-11, 16:31
	> А затем пользователь должен решить, какую из > процедур ему запустить: [...] > - рекурсивное удаление оборваной (stale) ветви (portmaster -s) Живо напомнило поиск оборванных цепочек кластеров на продвинутой Таблице Размещения Файлов. Практика всё-таки показывает, что чисто там, где не гадят.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	39. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	–1 +/–
	Сообщение от DeadLoco (ok) on 03-Янв-11, 17:01
	> Живо напомнило поиск оборванных цепочек кластеров на продвинутой Таблице Размещения Файлов. > Практика всё-таки показывает, что чисто там, где не гадят. С графами управляться можно только ограниченным количеством способов.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	40. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 03-Янв-11, 17:46
	>> Живо напомнило поиск оборванных цепочек кластеров на продвинутой >> Таблице Размещения Файлов. > С графами управляться можно только ограниченным количеством способов. Акцент не на "после обрыва", а на "чисто там, где не гадят".
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	41. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	–1 +/–
	Сообщение от DeadLoco (ok) on 03-Янв-11, 17:59
	> Акцент не на "после обрыва", а на "чисто там, где не гадят". А что понимается под "гадить"?
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	48. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	–1 +/–
	Сообщение от Michael Shigorin (ok) on 04-Янв-11, 16:28
	>> Акцент не на "после обрыва", а на "чисто там, где не гадят". > А что понимается под "гадить"? Например, рвать граф зависимостей.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	54. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от DeadLoco (ok) on 05-Янв-11, 07:32
	>> А что понимается под "гадить"? > Например, рвать граф зависимостей. Задумался о непрерывных преобразованиях графов :)
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	43. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от vle (ok) on 03-Янв-11, 18:53
	>> затем что в dpkg не было флагов "автоматически установлен" и нет до сих пор >> + нет всяких "автоматически установлен по рекомендации" > А в чем разница между "автоматически установлен" и просто "установлен"? Если пользователь установил пакет "А", значит именно он предоставляет нужную ему функциональность, а не те 25 зависимостей, которые нужны для ее реализации. Поэтому после удаления пакета "А", 25 зависимостей также становятся ненужными, при условии, что они не нужны другим пакетам пользователя. Это же очевидно. > Есть флаг REQUIRED_BY и депенденсы - разве их недостаточно для проверки связности > графа? Связность графа вообще не имеет отношения к делу. Если считать пакеты вершинами орграфа, а DEPENDS ребром, то установленные пакеты представляют из себя ациклический орграф, несвязный чаще всего, посколько есть пакеты, не требующие ничего и от которых ничего не зависит. По крайней мере так в pkgsrc и FreeBSD ports, где пакетная система предъявляет некоторые требования к окружению (для простоты к базовой системе). Одним словом. Связность графа и понятие "установлено по зависимости" ортогональны.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	45. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от DeadLoco (ok) on 04-Янв-11, 00:08
	> Связность графа и понятие "установлено по зависимости" ортогональны. Бинго! Именно это я и твержу. Поскольку установленные порты образуют граф, и для графа ортогонально понятие "установлено по зависимости", то реализация этого понятия в тулзах управления портами видится бессмысленной. > установленные пакеты представляют из себя ациклический орграф, несвязный чаще > всего, посколько есть пакеты, не требующие ничего и от которых ничего не зависит. > По крайней мере так в pkgsrc Какой кошмар. Согласиться с вышесказанным могу лишь в части "установленные пакеты представляют из себя ... орграф". Ну, и то, что так в пкжсрц - допускаю, хотя и не уверен. 1. порты - граф очень даже циклический. 2. порты - граф предельно связный в норме, потому что порты без депендов и реквайров являются листьями корневого узла. Несвязность графа портов означает необходимость ручного вмешательства и принятия решения - удалить отпиленное или перепривить на другой узел. Если в пкжсрц не так, то он не жилец на этом свете.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	46. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от vle (ok) on 04-Янв-11, 00:22
	> 1. порты - граф очень даже циклический. Приношу свои соболезнования.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	55. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от DeadLoco (ok) on 05-Янв-11, 07:35
	>> 1. порты - граф очень даже циклический. > Приношу свои соболезнования. А если подумать?
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	56. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от vle (ok) on 05-Янв-11, 12:00
	>>> 1. порты - граф очень даже циклический. >> Приношу свои соболезнования. > А если подумать? А если подумать, я не знаю, что ответить на феерический бред. Могу только порекомендовать книгу почитать. Например, эту     * Кристофидес Н.Теория графов. Алгоритмический подход. М.: Мир, 1978. 429c.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	57. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	–1 +/–
	Сообщение от DeadLoco (ok) on 05-Янв-11, 12:13
	> А если подумать, я не знаю, что ответить на феерический бред. Чтобы не нагнетать ненужное противостояние, намекну лишь, что желаемое и фактическое состояние дерева портов может очень сильно различаться. Во всяком случае, сооружение двух портов, которые после установки будут образовывать контур в дереве, мне не представляется таким уж феерическим бредом.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	61. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от kshetragia (ok) on 10-Янв-11, 07:29
	А вот за это нужно бить по рукам! Хватит нам и RPM-ов.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	62. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от JL2001 (ok) on 10-Янв-11, 14:50
	> А вот за это нужно бить по рукам! Хватит нам и RPM-ов. раскройте мысль
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	63. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от kshetragia (ok) on 12-Янв-11, 10:44
	Я про "создание контуров". RPM славится тем, что некоторые пакеты имеют перекрестные зависимости друг на друга. Их приходится ставить/удалять одновременно. Что может говорить только о кривости разбивки на пакеты.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	64. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от JL2001 (ok) on 13-Янв-11, 00:50
	> Я про "создание контуров". RPM славится тем, что некоторые пакеты имеют перекрестные > зависимости друг на друга. Их приходится ставить/удалять одновременно. Что может говорить > только о кривости разбивки на пакеты. почему это ? например нечто вроде плеер-коре (требует хотя бы одну из плеер-гуи-из-*) плеер-гуи-из-консоли (зависит от плеер-коре) плеер-гуи-из-куте (зависит от плеер-коре) они друг без друга смысла не имеют коре и гуишка
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	65. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от www2 (??) on 13-Янв-11, 11:02
	>они друг без друга смысла не имеют коре и гуишка Имеют они смысл друг без друга или не имеют - не системы дело. Может быть я хочу оставить только пакет коре, а из стороннего репозиторий установить пакет веб. Но нет, этот ваш "смысл" будет диктовать мне установить что-нибудь ещё. Этот ваш "cмысл" должен учитываться в системе рекоменадций и в системе отслеживания пакетов, установленных вручную? Вот если бы коре был установлен по зависимости от гуи, то при удалении гуи можно было бы предложить удалить заодно и коре (известно что установлено вручную). Но если я поставил коре, то можно лишь порекомендовать мне поставить ещё и гуи (известны рекомендуемые пакеты), но не обязывать меня его ставить.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	66. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Michael Shigorin (ok) on 15-Янв-11, 20:45
	>>> Что может говорить только о кривости разбивки на пакеты. Обычно да, но изредка это объективная проблема апстрима или вообще задачи.  Примеры сходу не вспомню, но очень редко встречал. >> они друг без друга смысла не имеют коре и гуишка > Имеют они смысл друг без друга или не имеют - не системы дело. Для такого ССЗБ в rpm всё равно есть опции --no.... --fo... (потому как local root'у и решать); вот только я пока ещё не видел разумного системного администратора, которому бы в трезвом уме, здравой памяти и штатной ситуации такое потребовалось. > Может быть я хочу оставить только пакет коре, а из > стороннего репозиторий установить пакет веб. Если сторонний репо не озадачился поставкой замкнутого по зависимостям на себя плюс базовый репозиторий *-core + *-web (в таком примере), то сляпали его ухари и пользоваться им будет разве что опять же ССЗБ. Потому как если *-core в базовом собран, скажем, без опционального ssl, а *-web вдруг с, то вся каша вместе может банально сегфолтиться из-за разной длины структур данных на стыке.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	67. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от vle (ok) on 15-Янв-11, 22:33
	>>>> Что может говорить только о кривости разбивки на пакеты. > Обычно да, но изредка это объективная проблема апстрима Проблема апстрима -- пожалуй, да > или вообще задачи.   А вот это вряд ли > Примеры сходу не вспомню, но очень редко встречал. Так есть в альте циклические зависимости между rpm-ами или нет?
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	68. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Michael Shigorin (ok) on 16-Янв-11, 00:04
	>> Примеры сходу не вспомню, но очень редко встречал. > Так есть в альте циклические зависимости между rpm-ами или нет? Наверняка да, но давно не сталкивался/интересовался.  Тема всплывает обычно при портировании (x86_64, ppc, arm).
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	73. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от dukzcry on 21-Дек-11, 23:30
	Ого, я поражен, дискуссирующие тут о графах - вы взрослые дядьки, я лет на 10 вас младше, а азы дискретной математики у меня уже из головы вылетели :-(
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	69. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от nuclight (ok) on 19-Янв-11, 12:40
	>>> 1. порты - граф очень даже циклический. >> Приношу свои соболезнования. > А если подумать? А чего там думать? Такое явно запрещено политикой проекта (и если на короткое время такое вдруг образовывается, это баг, который фиксят, а не нормальные условия работы).
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	70. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от DeadLoco (ok) on 19-Янв-11, 15:53
	> А чего там думать? Такое явно запрещено политикой проекта (и если на > короткое время такое вдруг образовывается, это баг, который фиксят, а не > нормальные условия работы). Но возникновение циклов в графе портов возможно? Хотя бы гипотетически?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	71. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от nuclight (ok) on 19-Янв-11, 16:40
	>> А чего там думать? Такое явно запрещено политикой проекта (и если на >> короткое время такое вдруг образовывается, это баг, который фиксят, а не >> нормальные условия работы). > Но возникновение циклов в графе портов возможно? Хотя бы гипотетически? Я, пожалуй, к предыдущему оратору присоединюсь.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	21. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от Aquarius (ok) on 02-Янв-11, 23:24
	>> затем же, зачем было писать для NetBSD (pkgsrc гибче ports) > Чем pkgsrc в NetBSD гибче FreeBSD ports? уже неравенство в зависимостях вместо только пути порта (<категория>/<порт>) многого стоят
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	24. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+1 +/–
	Сообщение от vle (ok) on 03-Янв-11, 01:08
	Главная и первоочередная цель nih-а -- это все-таки безболезненные бинарные апдейты, а source-based немного позже, поэтому крен немного другой. А в целом да, управление пакетами.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

59. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
Сообщение от Anonymous123 on 10-Янв-11, 00:03
А почему не НАХ, а НИХ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	60. "Для PkgSrc представлен APT-подобный пакетный менеджер nih"	+/–
	Сообщение от vle (ok) on 10-Янв-11, 00:25
	NIH = Not Invented Here http://en.wikipedia.org/wiki/Not_Invented_Here
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

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

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