:))))) По гиперболической, через бесконечность холиваров! :))))
Список — нигде, чисто наблюдение за специфическими статьями чистых знаний, где минусовать без комментария не за что :)
В примере используется локальный репозиторий: ему не нужны никакие апачи :)
При добавлении репозитория вместо протокола http используется протокол file, и всё супер :)
Именно в данном случае я бы не стал заморачиваться, и просто переделал бы существующий Zabbix пакет :)) Убедившись что всё работает, конечно.
Конечно, вручную всегда интереснее, и меньше шансов упустить важные моменты. У Вас получился самый наглядный из виденных мной инструкций по созданию source пакетов, спасибо! :) Повешу у себя ссылку :)
Я, конечно, не имел дела с rpm, но что-то мне подсказывает, что вы просто не читали полную документацию возможностей :) Deb пакет тоже можно сделать ограничившись одним файлом: DEBIAN/control ;)
Именно поэтому я и описал простой способ создания собственного репозитория: просто добавьте ваши убежавшие зависимости в него, и всё установится как по маслу :)
Расшарить репозиторий апачем — задача тривиальная, и позволит устанавливать всю эту пачку на всех машинах в сети. А если эту болванку репозитория выкинуть на VDS… ;)
Верно. Человек ленив по своей природе :)
Я сейчас как раз работаю над интерактивной прогой (не мудрствуя, консольный php скрипт), которая задаёт юзеру вопросы и генерирует этот каркас пакета так, что останется лишь немножко подредактировать контрольный файл :) Когда она будет достаточно мощна для распространения и проверена — срелизну)
Конечно можно!
Но принято создавать маленький пакет, зависящий от всех необходимых. В него также складываются все те вещи, которые предположительно меняются чаще остальных.
Например, для игр обычно главный пакет — архитектурозависимые бинарники: для них патчи выходят часто. А графика и звук раскладывается в завимимые отдельные пакеты: они обновляются реже, и пользователям не придётся качать всю графику снова :)
Кроме того, заворачивать все зависимости в один пакет — это очень уж по виндузятному :) Разрешение зависимостей придумывали как раз чтобы не заниматься подобной ерундой, у которой есть минимум один серьёзный недостаток: врядли вы будете обновлять все эти зависимости при выходе заплаток ;)
Упростить можно :) Прочитайте, вдумайтесь, по мере чтения — создавайте шаблоны файлов, подходящие именно Вам. Оставьте там свои комментарии: личные заметки всегда понятнее любых статей. Получится скелет, который с минимальными изменениями копипастится для создания нового пакета, и урезается до необходимого минимума :)
А ещё проще — упомянутый checkinstall. Для простых пакетов подходит идеально :)
Ему не обязательно давать команду «make install» для дебианизации: это может быть и скрипт с «mv * /usr/local/bin». Чекинсталлу по барабану за чем наблюдать :)
[pedantic] Такие программы должны называться сервисом/демоном, лучше — виджетом, но уж никак не сервером! :) Где же тогда удалённые пользователи, раз это — сервер? :)))
Список — нигде, чисто наблюдение за специфическими статьями чистых знаний, где минусовать без комментария не за что :)
При добавлении репозитория вместо протокола http используется протокол file, и всё супер :)
Конечно, вручную всегда интереснее, и меньше шансов упустить важные моменты. У Вас получился самый наглядный из виденных мной инструкций по созданию source пакетов, спасибо! :) Повешу у себя ссылку :)
Расшарить репозиторий апачем — задача тривиальная, и позволит устанавливать всю эту пачку на всех машинах в сети. А если эту болванку репозитория выкинуть на VDS… ;)
Я сейчас как раз работаю над интерактивной прогой (не мудрствуя, консольный php скрипт), которая задаёт юзеру вопросы и генерирует этот каркас пакета так, что останется лишь немножко подредактировать контрольный файл :) Когда она будет достаточно мощна для распространения и проверена — срелизну)
Конечно можно!
Но принято создавать маленький пакет, зависящий от всех необходимых. В него также складываются все те вещи, которые предположительно меняются чаще остальных.
Например, для игр обычно главный пакет — архитектурозависимые бинарники: для них патчи выходят часто. А графика и звук раскладывается в завимимые отдельные пакеты: они обновляются реже, и пользователям не придётся качать всю графику снова :)
Кроме того, заворачивать все зависимости в один пакет — это очень уж по виндузятному :) Разрешение зависимостей придумывали как раз чтобы не заниматься подобной ерундой, у которой есть минимум один серьёзный недостаток: врядли вы будете обновлять все эти зависимости при выходе заплаток ;)
А ещё проще — упомянутый checkinstall. Для простых пакетов подходит идеально :)
Ему не обязательно давать команду «make install» для дебианизации: это может быть и скрипт с «mv * /usr/local/bin». Чекинсталлу по барабану за чем наблюдать :)