The OpenNET Project / Index page

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



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

Оглавление

Проект GNU начал развитие нового пакетного менеджера Guix, opennews (??), 23-Ноя-12, (0) [смотреть все] +1

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


143. "Проект GNU начал развитие нового пакетного менеджера Guix"  –1 +/
Сообщение от sarbashemail (ok), 24-Ноя-12, 20:38 
Всё это напоминает обострение синдрома NIH...
Разве не пакетный менеджер решает проблему зависимостей и dll-hell?
Зачем рядовому пользователю возможность установки приложений?
В Enterprise сие под контролем админа, я на своём локалхосте прекрасно решаю задачу установки с помощью штатного пакетного менеджера, мой личный home полностью под моим контролем и бинарникам в нём нечего делать (конечно, есть исключения, в пределах разумного, не превращать же home/bin в подобие /usr/bin!!).

Зачем транзакции? Разве пакетный менеджер не может проконтролировать установку и в случае неудачи её отменить?

Потом, это отдельное дерево пакетов или даже в каталоге пользователя! И что, терминал уже не в моде? всё запускаем с помощью ярлычков на десктопе? здравствуй виндолинукс? А как же $PATH?

Вообще, столько вопросов сразу поднимается. Не понятно, зачем они это затеяли...
Ну, раз кому-то это нужно и даже нравится, что ж - желаю удачи.

P.S. Самолично пользуюсь aptitude, до этого был pacman.

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

146. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от sarbashemail (ok), 24-Ноя-12, 21:19 
>Это не транзакция?

Если это - транзакция, то пакетный менеджер без неё - не пакетный менеджер.

>Не вижу логики. Как каталог связан с терминалом и ярлыками?

Логика была в возможности запуска любого приложения из любого места (меню, gmrun, строка терминала, mc, something else...).

Как я понял, проблему *.so они решили прописыванием зависимостей. Интересно, а где общие либы будут лежать? У каждого приложения по своему экземпляру либы? Ибо независимость от системного окружения. Не понимаю, как вообще этот вопрос решили?

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

147. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Kolya (?), 24-Ноя-12, 21:42 
>Если это - транзакция, то пакетный менеджер без неё - не пакетный менеджер.

тогда пакетных менеджеров намного меньше, чем ты думаешь.

>Логика была в возможности запуска любого приложения из любого места (меню, gmrun, строка терминала, mc, something else...).

ну есть же $HOME/bin и симлинки.

>Как я понял, проблему *.so они решили прописыванием зависимостей. Интересно, а где общие либы будут лежать? У каждого приложения по своему экземпляру либы? Ибо независимость от системного окружения. Не понимаю, как вообще этот вопрос решили?

незнаю как они решили, но в man ld.so много переменных интересных переменных окружения. Например: LD_LIBRARY_PATH. Можно использовать симлинки :D

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

159. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от sarbashemail (ok), 24-Ноя-12, 22:16 
> ну есть же $HOME/bin и симлинки.

Когда я размышлял над темой, у меня проскальзывала такая мысль, что, вероятно, будет 100500 симлинков. При таком раскладе, это первое очевидное решение проблемы.
Ладно, пусть велосипедят, в свете последних событий, вообще уже ничего не удивляет.
Даже не приходит в голову, что ещё не успели навелосипедить... система инициализации? графическая система? стандарт файловой иерархии?

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

258. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Crazy Alex (ok), 26-Ноя-12, 15:47 
шелл ещё вроде держится, тьфу-тьфу...
Ответить | Правка | Наверх | Cообщить модератору

158. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от ананим (?), 24-Ноя-12, 22:14 
>Интересно, а где общие либы будут лежать?

на самом деле вообще не интересно.
важно в где и в какой последовательности их будет искать ldd при запуске конкретного приложения.

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

157. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от ананим (?), 24-Ноя-12, 22:10 
>>Разве не пакетный менеджер решает проблему зависимостей и dll-hell?
>пакетный менеджер не решает проблему dll-hell. У него не достаточно для этого информации.

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

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

161. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Kolya (?), 24-Ноя-12, 22:33 
какая связь между разрешение зависимостей(по имени пакеты или имени файла) и ABI библиотеки? Ну нету этой инфы в пакете. Она даже не всегда доступна людям собирающим эти пакеты. Ты, что думаешь, я не смогу собрать пакет, который заменит libx264.so.120 на libx264.121? Всего то один mv, и всё... всё в руках вменяемого мейнтейнера.
Ответить | Правка | Наверх | Cообщить модератору

165. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от ананим (?), 24-Ноя-12, 22:56 
>какая связь между разрешение зависимостей(по имени пакеты или имени файла) и ABI библиотеки? Ну нету этой инфы в пакете.

правильно. никакой. :D
>Ты, что думаешь, я не смогу собрать пакет, который заменит libx264.so.120 на libx264.121? Всего то один mv, и всё... всё в руках вменяемого мейнтейнера.

правильно, можешь. :D
как и вындусовый ливапдэйт может сделать формат ц.
как андроидовский гуглплай может… и тд, и тп.

и тем не менее пакетный мэнеджер не перезапишет библиотеки одного пакета библиотеками другого. поэтому он решает проблему dll-hell.
и чтобы все-таки установить эту вторую программу, мэнтейнеру (или разработчику) придётся переписать пакет таким образом, чтобы эти библиотеки не конфликтовали.
полное ли это решение dll-hell? нет. а его вообще нет.

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

168. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Kolya (?), 24-Ноя-12, 23:04 
>и тем не менее пакетный мэнеджер не перезапишет библиотеки одного пакета библиотеками другого.

а ты пробовал?

>нет. а его вообще нет.

100%-ного нет, зато...
1) можно ввести информацию по интерфейсам, которые обеспечивает либа(привет .net)
2) повесить заботу об этих либах на специальный механизм, который сам будет давать им уникальные имена(например: рандомные)
3) использовать БД с ключами интерфейс:либа, или <имя либы><мажорная версия>:либа

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

173. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от ананим (?), 24-Ноя-12, 23:32 
>а ты пробовал?

а ты нет?
>100%-ного нет, зато...
>1) можно ввести информацию по интерфейсам, которые обеспечивает либа(привет .net)
>2) повесить заботу об этих либах на специальный механизм, который сам будет давать им уникальные имена(например: рандомные)
>3) использовать БД с ключами интерфейс:либа, или <имя либы><мажорная версия>:либа

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

при этом первый приводит к регистрихэлл, а первый/второй/третий/четвёртый к дополнительным расходам ресурсов (в винде вон несколько гигов под это дело).
если перфразировать задачу с «избавиться от dll-hell окончательно» на «предоставить такие истструменты в системе, чтобы можно было разрулить потенциальный dll-hell», то линух для этого отлично подходит — можно любой блоб (!!!) заставить работать установив и переконфигурировав необходимое. исключение составляет привязка к glibc/ но и это обходится.
а в винде этого сделать нельзя (разве что на дотнете :D)

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

174. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Kolya (?), 24-Ноя-12, 23:39 
1-3 -- это не 'или', а 'и'.
Ну гарантия, конечно, всё ещё никакая.

Про всё остальное: офигеть ты фанатик. В винде -- тоже самое и всегда было. Просто, положить либу в директорию проще всего.

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

178. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от ананим (?), 24-Ноя-12, 23:58 
с одной стороны — все твои 1/2/3
с другой — добавить пару строчек в окружение программы.
>В винде -- тоже самое и всегда было. Просто, положить либу в директорию проще всего.

да-да!! :D
именно так там и появился dll-hell (1с 2.0 отлично в него попадала с установкой ole.dll)
потом пошли ком, с регистрацией и прочими плюшками (а как их удобно программировать! :D)
потом манифесты интерфейсов, потом гигабайтные кэши http://en.wikipedia.org/wiki/Side-by-side_assembly
>Microsoft Visual C++ 2005 and 2008 employ SxS with all C runtime libraries. However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name
>Disadvantages
>* Only supported on Windows XP and later. In Windows XP, a bug in sxs.dll causes heap corruption, leading to application crashes. This issue is not fixed by any XP service packs. Users must manually install a QFE (Quick Fix Engineering).
>* Considerably higher disk space consumption. The winsxs directory typically starts at several gigabytes

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

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

179. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Kolya (?), 25-Ноя-12, 00:02 
вот чёрт. Мне теперь писать в какую директорию положить? Я имел ввиду НЕ systemXY
Ответить | Правка | Наверх | Cообщить модератору

182. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от ананим (?), 25-Ноя-12, 00:03 
а длл-хэлл в НЕ systemXY НЕ наступает.
Ответить | Правка | Наверх | Cообщить модератору

186. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Kolya (?), 25-Ноя-12, 00:13 
Я знаю это.
Вот тут https://www.opennet.ru/openforum/vsluhforumID3/87443.html#139 написано:
>/usr/libXX

А там я написал про директорию потому, что ты сказал(https://www.opennet.ru/openforum/vsluhforumID3/87443.html#169):
>если скайп, опера, жопера идёт со своими библами для внутреннего использования, то >единственное с чем она может столкнуться, то это с совпадением имени файла при бедной >фантации разработчиков. но поскольку в линухе можно легко строить структуры каталогов, то >это не вызывает проблем

но и в винде в ProgramFiles можно и не такое сделать.

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

189. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от ананим (?), 25-Ноя-12, 00:17 
поэтому говорим о систем32
Ответить | Правка | Наверх | Cообщить модератору

181. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Kolya (?), 25-Ноя-12, 00:03 
с остальным спорить сложно. Но в линуксе от этого хелл не исчезает, а что там в винде не так важно.
Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

184. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от ананим (?), 25-Ноя-12, 00:12 
хелл исчезает из-за 2-х факторов — 1) гибкое окружение (теперь даже глибс можно через контейнер другой пустить) и 2) пакетные мэнеджеры, не допускающие установки вручную (аля setup.exe и вопросом «а вы уверены?». вот у кого они спрашивают? у пользователя? чтобы на него ответственность переложить не более)

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

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

194. "Проект GNU начал развитие нового пакетного менеджера Guix"  +1 +/
Сообщение от sarbashemail (ok), 25-Ноя-12, 01:25 
http://ru.wikipedia.org/wiki/DLL_hell

Нет в Linux никакого DLL-hell. Возможен Dependency-hell, решить который и призван пакетный менеджер. И вполне себе решает.
А то, что вытворяет объект обсуждения - либо сплошная статика (память нынче дешёвая), либо "атака кло(у)нов", либо - выкрутасы с симлинками и помойка в файловой системе.

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

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

231. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Michael Shigorinemail (ok), 25-Ноя-12, 20:20 
>>и тем не менее пакетный мэнеджер не перезапишет библиотеки одного пакета
>>библиотеками другого.
> а ты пробовал?

Я -- да; rpm откажется производить установку по причине файлового конфликта.

>> нет. а его вообще нет.

Можно и 100%, только накладные расходы становятся заметными.

> 100%-ного нет, зато...

#230

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

185. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от filosofem (ok), 25-Ноя-12, 00:12 
> какая связь между разрешение зависимостей(по имени пакеты или имени файла) и ABI
> библиотеки? Ну нету этой инфы в пакете. Она даже не всегда доступна людям собирающим эти пакеты.

Дану? Эта инфа в major version number в SONAME, а так же в имени бинарника и в имени пакета.

> Ты, что думаешь, я не смогу собрать пакет, который заменит libx264.so.120 на libx264.121? Всего то один mv,
> и всё... всё в руках вменяемого мейнтейнера.

От дурака майнтейнера никто конечно не застрахован. Тем не менее твоего mv совсем не достаточно, чтобы устроить dll-hell.

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

190. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от filosofem (ok), 25-Ноя-12, 00:22 
> И чем он лучше аттрибутов(или как там их) у файлов в винде?
> таже самая филькина грамота

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

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

230. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Michael Shigorinemail (ok), 25-Ноя-12, 20:18 
> какая связь между разрешение зависимостей(по имени пакеты или имени файла)
> и ABI библиотеки? Ну нету этой инфы в пакете.

Где как, в альте уже несколько лет как есть (google:rpm set-versions).

PS: когда не знаете, лучше и не утверждать.
PS: а когда утверждаете глупости вроде "у кого есть soname, кроме openssl" (#188) -- временно увеличиваете количество мусора, не более.

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

232. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Kolya (?), 25-Ноя-12, 20:41 
ах, ну да. Нет других дистров кроме altlinux
Ответить | Правка | Наверх | Cообщить модератору

241. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от arisu (ok), 26-Ноя-12, 02:57 
> ах, ну да. Нет других дистров кроме altlinux

забавный ты клоун. если ты говоришь, что «нет дистра кроме того, у которого нет такой инфы в пакете» — не обращая внимания, что такие есть, — ты Вещаешь Истину. а когда тебя тычут носом в твои ошибки — все гадысволочифашистытролли.

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

245. "Проект GNU начал развитие нового пакетного менеджера Guix"  +/
Сообщение от Kolya (?), 26-Ноя-12, 11:07 
>«нет дистра кроме того, у которого нет такой инфы в пакете»

фишка в том, что я не говорил этого. Я спросил у filosofem, есть ли такие пакеты. Но он, к сожалению, не ответил. А эта моя ошибка(а это ошибка) связана с тем, что в slackware я напарывался на "ошибку" в задании имени именно у openssl.

Мой ответ шигорину был про rpm, и пакетный менеджер в слаке именно перекрывал. По карайней мере в 12 версии.

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

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

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




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

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