Проверяем программу установки пакетов

[Lego]

Если допустить возможность установки пакетов не из Gaff (обязательно надо допустить, где ж свобода  тогда), то автоматическое "докачивание" зависимостей, имхо, не приветствуется. В идеале: проверка на зависимости - их список - предложение зеркал с возможностью отказаться и установить вручную. Сейчас: Постановка перед фактом, что будет что-то скачано из интернета.

[andy-voit]

Попробовал. Чего-то он (petget) не захотел ставить пробный пакет. Окно выскочило с предложением установить - ок - ускочило обратно и .... Всё, больше ничего. Не копал причину, вернул get_pet. Можно и с ним жить, просто в случае установки из локальных источников инет лучше отрубить от греха подальше.

Всего лишь имеем недоработанный petget в репо. Нужно либо убирать, либо доделать. Лучше доделать - это решит проблему раз и навсегда.

4. Автоматическая установка зависимостей все таки не приветствуется

А вот с этим я не согласен категорически. По крайней мере, должен быть выбор.

[Pro]

А вот с этим я не согласен категорически. По крайней мере, должен быть выбор.

аргументируйте ваше мнение, плиз.

[andy-voit]

аргументируйте ваше мнение, плиз.

Наверное, каких то особо убойных аргументов у меня нет, кроме того, что
1. автоматически - это чертовски удобная штука.

Просто видимо пункт 4 сформулирован слишком категорично. Я бы согласился все же с Олегом

В идеале: проверка на зависимости - их список - предложение зеркал с возможностью отказаться и установить вручную.

[Pro]

А теперь я вам распишу все возникшие проблемы:
1. одна и таже библиотека может входить в несколько пакетов например libnss.so есть как в собственном пакете nss, так и в составе некоторых браузеров, и с точки зрения существующей программы установки какой пакет выбрать? не факт что будет выбран именно пакет nss, может и браузер подтянуть.
2. в репозитарии может существовать несколько версий одного и того же пакета, я стараюсь чтобы было не более двух, процедуры выбора наиболее предпочтительного пакета не отработаны, и реализовать будет затруднительно.
3. Зависимости "второй волны" - т.е. выбрали вы пакеты, автоматически добавились пакеты зависимостей и ..... снова идет поиск зависимостей и снова надо качать пакеты.

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

[DdShurick]

1. одна и таже библиотека может входить в несколько пакетов

Это было решено ещё в Jeans.

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

Да. Но надо хорошо подумать.

[andy-voit]

А зачем два пакета одной и той же или библиотеки? Конечно, скрипт будет путаться, или выбирать самую первую по алфавиту, т.е. самую старую-у нее цифра версии меньше.
На мой взгляд во многих случаях достаточно одной,наиболее новой. Обновление репо может строится таким образом - появилось обновление - старую долой, может не сразу, а после небольшого "карантина". Или я не прав?
Разумеется, вышесказанное относится только к зависимостям.

[Pro]

А зачем два пакета одной и той же или библиотеки? Конечно, скрипт будет путаться, или выбирать самую первую по алфавиту, т.е. самую старую-у нее цифра версии меньше.

а потому что вновь скомпилированные библиотеки могут работать "не так" и это "не так" мне встречается сплошь и рядом. Кроме того если это не библиотека а программа удобно копировать файлы настроек из более старой версии, ярлыки, ассоциации mime и другое, что обычно забывают делать или проверять те кто собирает пакет.

Обновление репо может строится таким образом - появилось обновление - старую долой, может не сразу, а после небольшого "карантина". Или я не прав?

не прав, это замечательно смотрится со стороны.... пока не начнешь это делать сам.

Цитата: Pro от Сегодня в 22:26:17
Теперь хочу услышать доводы о том что данные проблемы несущественны и спокойно могут быть реализованы в скрипте.
 Да. Но надо хорошо подумать.

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

[DdShurick]

 Я подумал, и вернулся к самому началу. ИМХО пакеты должны создаваться с полностью удовлетворёнными зависимостями. Как sfs. С двойной установкой библиотек вопрос давно решён. Перерасход трафика несоизмерим с расходами трафика и времени на поиск зависимости. Тем более, что зачастую вместе с необходимой библиотекой приходится в нагрузку скачивать совершенно не нужные файлы. Зато любой пакет может быть закачан откуда угодно и установлен одним кликом. Думаю, что это самое простое и эффективное решение, особенно для начинающих.
 Сборка sfs будет производиться далеко не новичками. Тут излишняя автоматизация неуместна. Поэтому надо писать отдельный скрипт.
 Как второй вариант можно сделать по образцу puppyrus-2, где в отдельном каталоге lib положены специально препарированные пакеты, содержащие только библиотеки. Но это гораздо более трудозатратный путь.

[sfs]

Сборка sfs будет производиться далеко не новичками.

Может собрать для новичков и ленивых основные программы (хотя бы из перечня средне-буржуйского puppy) готовыми модулями usoft*.sfs ? 1 прога -1 модуль? И выложить аналогично .pet

[Pro]

Я подумал, и вернулся к самому началу. ИМХО пакеты должны создаваться с полностью удовлетворёнными зависимостями. Как sfs.

а проблемы при создании sfs с несколькими программами в которых могут оказаться разные версии одних и тех же библиотек которые при наложении дадут полную ахинею и неразбериху. это продумано?

sfs, предлагать делать одна програма - один модуль sfs просто неэтично, вы не выносили данный вопрос в обсуждение концепции.

Господа, будьте реалистами, я предлагаю простое исправление существующего get_pet, вы предлагаете ВСЕ переделать: репозитарий, программу установки, концепцию пакетов. И как отслеживать проверяющему чего там за либы напиханы в пакет.

[DdShurick]

 "Будьте реалистами - требуйте невозможного!"
Саша, переделывать придётся рано или поздно. Нельзя идти сразу по нескольким путям. Придётся или организовывать каталог в репозитории для библиотек (Gaff/lib), или смириться с закачкой из существующего "зоопарка" попутного "мусора", который в свою очередь может потребовать свои зависимости. Впрочем, если у тебя есть "простое исправление get_pet" - предлагай.
Лично я использую пакеты как кирпичики для создания usoft. В мою систему Richy-user pet-пакеты устанавливать бессмысленно из-за отсутствия сохранёнки. Я даже get_pet удалил за ненадобностью.

[Pro]

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

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

Мои предложения я уже высказал и предложил тонкости обсудить в жабере.

[DdShurick]

 Смотрим build_sfs - скрипт для сборки SFS.

[Pro]

кто тестировал отписываем замечания сюда

DdShurick, get_pet исправленный ждать (без функции создания sfs)? и поддержка ftp поверх http будет включена или оно одновременно никак не будет работать?