LINUX.ORG.RU

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


0

1

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

#/bin/bash
aptitude install xxx yyy zzz
[hg|git] clone repo
blah blah blah
?

★★★★

Ответ на: комментарий от backbone

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

aptyp ★★★★
() автор топика

Использую

# DEPENDENICES: # blah, blah, blah

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

pztrn ★★★★
()

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

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

qnikst ★★★★★
()
Ответ на: комментарий от pztrn

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

aptyp ★★★★
() автор топика
Ответ на: комментарий от aptyp

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

qnikst ★★★★★
()

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

dave ★★★★★
()

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

trashymichael ★★★
()

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от amazpyel

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

pztrn ★★★★
()
Ответ на: комментарий от aptyp

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

pztrn ★★★★
()
Ответ на: комментарий от anonymous

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

aptyp ★★★★
() автор топика
Ответ на: комментарий от pztrn

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

aptyp ★★★★
() автор топика
Ответ на: комментарий от dave

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

aptyp ★★★★
() автор топика
Ответ на: комментарий от true_admin

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

aptyp ★★★★
() автор топика
Ответ на: комментарий от pztrn

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

aptyp ★★★★
() автор топика
Ответ на: комментарий от aptyp

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

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

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

aptyp ★★★★
() автор топика
Ответ на: комментарий от aptyp

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

dave ★★★★★
()

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

mv ★★★★★
()
Ответ на: комментарий от mv

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

aptyp ★★★★
() автор топика
Ответ на: комментарий от aptyp

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

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

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

Zubok ★★★★★
()
Ответ на: комментарий от aptyp

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

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

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

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

Manhunt ★★★★★
()
Ответ на: комментарий от aptyp

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

pztrn ★★★★
()
Ответ на: комментарий от Zubok

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

aptyp ★★★★
() автор топика

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

buddhist ★★★★★
()
Ответ на: комментарий от aptyp

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

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

Zubok ★★★★★
()
Ответ на: комментарий от vurdalak

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

Альт же ;)

quiet_readonly ★★★★
()
Ответ на: комментарий от Zubok

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

aptyp ★★★★
() автор топика
Ответ на: комментарий от aptyp

Ок, я ещё не внимательно читал 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
Zubok ★★★★★
()
Ответ на: комментарий от Zubok

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

sudo aptitude install dependencies; git clone ... 

?[br]За git-buildpackage и за терпение спасибо.
aptyp ★★★★
() автор топика
Ответ на: комментарий от aptyp

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

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

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

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

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

Zubok ★★★★★
()
Ответ на: комментарий от aptyp

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

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

Zubok ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.