Использование пакетного менеджера для разработки

В Gentoo возможна установка из dcvs-репозитория.

Гента вообще няшка, но не её использую.

Использую

# DEPENDENICES: # blah, blah, blah

Не дело это разработчиков - следить за установленными зависимостями на левых машинах ;)

В крайнем случае - сабмодули

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

не вижу ни одной причины делать такие скрипты, только если зависимости не closed source.

дело не в слежении и сабмодулях, а автоматизации развёртывания разрабатываемого окружение.

И ставишь вручную?

про closed source? Если этот проект является частью моего (я его пилю), то я держу для них свой каталог в ~/workspace/<vendor-name>/<project>, но я в этом репозитории и работаю. Несязанные (т.е. которые должны при этом жить в системе) зависимости из чужих закрытых репов ставить не приходилось, но для этого может сработать локальный оверлей.

Да, я во всю использую. Настроенный вручную asdf с периодическим использованием quicklisp для автоматической доустановки пакетов очень удобны в работе.

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

Эм

apt-get build-dep xxx

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

bundler спасает от костылей.

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

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

Юзер должен использовать пакетник, который разрулит сам. А если человек собирает LFS - это уже что-то большее, чем юзер, и он должен читать доки/хидеры сорцев на предмет указывания зависимостей ;)

сабмодули - и есть своего рода автоматизация

Что делает в Development этот ЖЖ-опрос?

чтобы мнение анонимусов узнать. причём тут жж? реальный вопрос.

яндекс использует

ммм, а ссылки под рукой нету?

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

не то.

который руби?

asdf многоязычный? Не только lisp интересует. У нас допустим проект имеет как клиентскую, так и серверную часть, вдобавок процедуры к базе.

ссылки под рукой нету?

http://softwaremaniacs.org/blog/2007/08/15/deb-packages-in-yandex/

+

знакомые там работают, те же истории рассказывали.

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

Тогда сабмодули и/или инструкция. Лень тут не должна присутствовать.

Я видимо тогда чего-то не понимаю в сабмодулях - допустим мне нужен glib, я использую его в своём проекте, сабмодуль позволяет установить libglib2.0-dev на систему?

а как ты хочешь в разработке использовать пакетный менеджер?

Или ты имеешь в виду скрипты типа apt-get install build-essential gdb ... ?

Есть проект А, его исходники (с мейкфайлом) хранится на гитхабе, его можно получить просто командой git clone ...., но проект использует различные либы, glib, lapack, cgal. и (допустим, в моём случае это не так), меняет файлы в системе, что-то обновляет, добавляет и т.д.
Я хочу сделать deb, которые всё это делает, в dependencies имеет используемые мною либы, чтобы когда участие какого-нибудь члена команды закончится, спокойно ввести apt-get remove very_important_project, чтобы всё стало, как будто ничего и не было.
P.S. и build-essential с gdb тоже нужны, да.

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

Думаю, что одноязычный. Это была шутка :)

#/bin/bash
aptitude install
git clone

То есть предлагается это из-под рута запускать?!

ммм, а как ты библиотеку установишь?

Софт пакуется в rpm и устанавливается штатным образом с помощью yum в el5/6. Для неудачников, кому их админы воткнули бубунту или сусю, поставляется привычный отавтотуленный тарболл.

Кто я, раз юзаю debian?)
Тут не про софт разговор, а как автоматизировать развёртывание разрабатываемой системы. Т.к. ручная установка и настройка в винде это ужасно, в линуксе тем более, раз тут пакетная система есть.

Само собой.

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

Я, если честно, ничего не понял. Тебе надо им поставить весь девелопмент из Debian, который вы используете для разработки? pbuilder вам в руки.

http://pbuilder.alioth.debian.org/

ммм, а как ты библиотеку установишь?

Через sudo, например.

Или вообще без рутовских прав обойдусь: соберу в локальный префикс из тарболла.

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

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

Разрабатываешь проект, один, держишь его на гитхабе, у него в зависимостях glib, lapack, cgal. К тебе в команду ещё десять человек приходят, не будешь же вручную клонировать репозиторий и ставить libglib2.0-dev, liblapack-dev, libcgal. Вот что автоматизировать хочу.

а, ну это да)

Не распарсил. Но я использую зависимости из пакетов.

Ну так а в чем проблема? Ставь списком. Там же не миллион библиотек перечислять.

Но еще раз обращу внимание, чтобы ты познакомился с pbuilder, так как у него все тобой установленные библиотеки хранятся в образе, который можно перенести на другую машину. Причем для каждой ветки можно иметь свой образ: один - с библиотеками stable, другой - с testing или sid. Для Ubuntu можно тоже сделать.

Такой скрипт не будет работать в не-deb дистрибутивах.

Альт же ;)

Ок, я ещё не внимательно читал main-guide, и руководство по pbuilder, задам глупый вопрос - можно, чтобы deb пакет выполнил git clone ?

Ок, я ещё не внимательно читал main-guide, и руководство по pbuilder

Я не совсем понимаю, в чем сложности, если честно. Упорно не понимаю. В чем проблема поставить библиотеки списком из репозитория? Кстати, а если у твоих разработчиков дистрибутив, основанный не на Debian? Пакетирование - это обычно процесс завершающий, а в процессе разработки зачем deb каждый раз собирать? Или пакет все время будет собираться из акутальных исходников?

задам глупый вопрос - можно, чтобы deb пакет выполнил git clone ?

Вопрос не глупый. Он неясный. Что значит, чтобы пакет выполнил? Пакет устанавливается, выполнить он может что-то в своих скриптах preinst, postinsts, prerm, postrm.

Если же речь идет об автоматической сборке пакета, исходники которого лежат в git, то есть git-buildpackage:

NAME
       git-buildpackage - Build Debian packages from a Git repository

А что означает «поставить библиотеки списком из репозитория»? Т.е. предлагается вручную

sudo aptitude install dependencies; git clone ... 

?[br]За git-buildpackage и за терпение спасибо.

А что означает «поставить библиотеки списком из репозитория»? Т.е. предлагается вручную

Это один из вариантов. Наиболее простой, чтобы не морочить голову разработчикам. Вот если бы ты поставлял им полноценный source-пакет для Debian, а не Git выдавал, то твои коллеги после установки исходников смогли бы сделать aptitude build-dep и все необходимые зависимости установились бы. А если из Git, то система не знает ничего про эту информацию. Так что еще такие варианты:

. Если они начнут собирать пакет, то debuild их предупредит, чего не хватает. Доставят по списку.

. С dpkg-checkbuilddeps можно сделать примерно то же. Его debuild и использует. Он проверит зависимости для сборки по control-файлу и выдаст список, чего не хватает.

. mk-build-deps содает специальный deb-пакет для удовлетворения зависимостей для сборки по debian/control (можно указать файл, можно зайти в каталог с исходниками). Но мне как-то не очень этот способ. Никогда не использовал, даже не знаю проблем.

И мне все равно не ясно. Дело в том, что если твои коллеги - разработчики, то нафига им deb собирать каждый раз? Как раз это и не нужно, потому что куча ненужных операций: конфигурирование, компиляция, сборка пакета deb, перемещение в репозиторий локальный (опционально), установка через apt или dpkg напрямую, пробуем. Ай, ошиблись! Все заново.

Тебе надо просто: скопилировал, попробовал, скомпилировал, попробовал и т. д. А пакет уже собирать, когда релиз.