https://mobile.opennet.me/openforum/vsluhforumID3/101298.html Создатели проприетарного программного продукта Biicode (https://www.biicode.com/), в рамках которого развивается менеджер зависимостей и репозиторий пакетов для кода на языках С/C++, сообщили (http://opensource.com/business/15/1/biicode-open-source-dependency-manager) об утверждении решения по переводу Biicode в разряд свободных проектов. Biicode можно рассматривать в качестве адаптированного для С/C++ аналога систем Pip (Python), Gems (Ruby), cpan (Perl), npm (Node.js) и Pub (Dart), предоставляющих средства для доустановки необходимых для сборки проекта зависимостей, а также поддерживающих репозиторий для публикации пакетов. <br> <br><br><br><br><br><br>По соглашению с инвесторами открытие кода Biicode будет произведено после того как число пользователей сервиса достигнет 10 тысяч. В настоящее время зарегистрировано (https://www.biicode.com/biicode-open-source-challenge) около 2500 аккаунтов. В рамках проекта Ryppl (https://github.com/ryppl/ryppl) уже предпринималась попытка создания подобного инструментария для C++, но п https://mobile.opennet.me/openforum/vsluhforumID3/101298.html#40 Mon, 17 Aug 2015 10:05:18 GMT Это типа maven-репозитория. Зависимости по-другому разруливаются.<br> https://mobile.opennet.me/openforum/vsluhforumID3/101298.html#39 Tue, 27 Jan 2015 21:37:08 GMT &gt;&gt; Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно <br>&gt;&gt; с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake.<br>&gt; o_O по моим сведениям использование autoconf/automake не приводит к появлению в системе <br>&gt; библиотек, неизвестных пакетному менеджеру системы, сами не ведут никакого учёта установленного <br>&gt; и сторого говоря пакетным менеджером не являются. во всяком случае в <br>&gt; портах и портежах это далеко не так. Я не спорю, что <br>&gt; при горячем желании это можно сделать, но пока я не видел <br>&gt; таких решений. А вот упомянутые pip/gems/cpan - видел, и применяются они <br>&gt; ровно так, как не надо.<br><br>Вы видели как порты и портежи используют pip/gems/cpan? Примерно так же как и autoconf/automake. Нет, я понимаю, что вас раздражает -- я назвал autoconf/automake пакетным менагером, вы же при этом считаете, что отслеживание зависимостей, установленных файлов, конфликтов между файлами и прочие функции -- неотъемлимыми атрибутами пакетного менаге https://mobile.opennet.me/openforum/vsluhforumID3/101298.html#38 Tue, 27 Jan 2015 21:17:19 GMT &gt; Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно <br>&gt; с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake.<br><br>o_O по моим сведениям использование autoconf/automake не приводит к появлению в системе библиотек, неизвестных пакетному менеджеру системы, сами не ведут никакого учёта установленного и сторого говоря пакетным менеджером не являются. во всяком случае в портах и портежах это далеко не так. Я не спорю, что при горячем желании это можно сделать, но пока я не видел таких решений. А вот упомянутые pip/gems/cpan - видел, и применяются они ровно так, как не надо.<br> <br>&gt;[оверквотинг удален]<br>&gt; к gentoo, я скажу, что можно конечно запилить пакетный менагер, которым <br>&gt; неудобно пользоваться из ебилда и проще реализовать всю логику сборки и <br>&gt; инсталляции заново, но если есть хотя бы 700 граммов мозга и <br>&gt; общая эрудиция в отношении методов распространения софта в *nix системах, то <br>&gt; вполне возможно создать пакетный менагер, кото https://mobile.opennet.me/openforum/vsluhforumID3/101298.html#37 Mon, 26 Jan 2015 06:32:02 GMT в безымянной<br> https://mobile.opennet.me/openforum/vsluhforumID3/101298.html#36 Sun, 25 Jan 2015 23:13:21 GMT &gt;&gt; Пакетные системы, функционирующие параллельно с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake <br>&gt; Идиот безмозглый, autotools это не пакетная система.<br><br>Расскажите ещё что-нибудь об autotools, у вас очень занимательно выходит.<br> https://mobile.opennet.me/openforum/vsluhforumID3/101298.html#35 Sun, 25 Jan 2015 21:05:23 GMT &gt; Пакетные системы, функционирующие параллельно с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake<br><br>Идиот безмозглый, autotools это не пакетная система.<br> https://mobile.opennet.me/openforum/vsluhforumID3/101298.html#34 Sun, 25 Jan 2015 19:28:02 GMT Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake. И унифицированная система сборки для, допустим, проектов на C++ может оказаться весьма удобной для строителей дистрибутивов. Ну, во-всяком случае, примеряя всё это к gentoo, я скажу, что можно конечно запилить пакетный менагер, которым неудобно пользоваться из ебилда и проще реализовать всю логику сборки и инсталляции заново, но если есть хотя бы 700 граммов мозга и общая эрудиция в отношении методов распространения софта в *nix системах, то вполне возможно создать пакетный менагер, который будет реальным подспорьем для мейнтейнеров дистрибутивов, а не чем-то в стиле "не пришей кобыле хвост." Да и для меня оно может оказаться удобным, в том смысле, что чем проще ебилды, тем проще их править, если мне вдруг потребовалось что-то особенное -- это значит что мне меньше придётся ставить всякого дерьма в обход emerge в домашнюю директорию https://mobile.opennet.me/openforum/vsluhforumID3/101298.html#33 Sun, 25 Jan 2015 18:02:14 GMT дураков типа тебя пинаю.<br> https://mobile.opennet.me/openforum/vsluhforumID3/101298.html#32 Sun, 25 Jan 2015 10:35:10 GMT дело идёт к тому, что на системные зависимости и пакетный менеджер всем будет наплевать. ничего не напоминает? некую систему, где библиотеки размещены в строгом порядке "кто где наср#$%л", каждая софтина имеет свой инсталлятор, свой обновлятор (если имеет), тащит за собой то, к чему её приколотили гвоздями.<br><br>выглядит как линуксокапец, но оптимизм внушает две вещи. <br>- ушлёпки с таким стилем программирования написать под несколько дистров не осиливают. <br>- фрагментация дистров оставляет варианты для тех, кому не надо из системы делать отхожее место.<br>