Комментарии 83
НЛО прилетело и опубликовало эту надпись здесь
Я очень редко его встречал, поэтому и не упомянул. Я на эту возможность никогда не рассчитываю.
Лучше бы он про checkinstall написал.
при этом правда нада исходники не удалять. И если потом сделать ./configure с другими параметрами, make uninstall уже может не совсем так же работать. Что, впрочем, очевидно.
проще ебилд написать за 5 секунд =)
проще ебилд написать за 5 секунд =)
все конечно хорошо, но кроме GNU build system есть и другие. лучший метод установки — прочесть сначала README, INSTALL etc. дальше по обстоятельствам
Цель статьи — показать начинающим возможности xstow по наведению порядка, кстати есть еще и другие методы, но у меня прижился этот.
если софтина собирается не autotools, то смысла в configure нет. make могут и полностью свой написать, а что там за таргеты будут, какие переменные окружения там используются — все зависит от разработчика. в конце-концов кто то захочет и прикрутит bash скрипт для инсталла и компиляции. если в посте основное — xstow, то следовало бы отразить это в названии :) а так, исходя из топика, хотел бы повторить для начинающих, что компиляция и установка программ, не входящих в дистрибутив начинается в первую очередь с чтения доков
добавлю-ка в избранное. спасибо
Под Убунту удобно после make, собирать пакет, а не ставить из исходников, с помощью checkinstall.
это все делает из убунты слакварь. не делайте так.
если сложно следовать вот этому
https://wiki.ubuntu.com/PackagingGuide/Complete
и этому
https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/basic-debhelper.html
то есть графические хелперы:
https://launchpad.net/~giftwrap/+archive/ppa
https://launchpad.net/gdebui
https://launchpad.net/debianpackagemaker
https://launchpad.net/debcreator
если сложно следовать вот этому
https://wiki.ubuntu.com/PackagingGuide/Complete
и этому
https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/basic-debhelper.html
то есть графические хелперы:
https://launchpad.net/~giftwrap/+archive/ppa
https://launchpad.net/gdebui
https://launchpad.net/debianpackagemaker
https://launchpad.net/debcreator
Не соглашусь. Считаю, у каждого решения своя ниша. Опять таки соответствует стандартам на файловую систему.
Пакеты, считаю, нужно собирать, когда поразумевается распространение или тестирование в составе софта дистрибутива.
Когда нужно что-то установить по быстрому, на «посмотреть», установить новую версию, вполне считаю допустимым сделать так как описано.
Вообще, традиционно, в UNIX есть три варианта установки, они сложились не зря, для каждого свое место.
1. Установка в домашнюю директорию
2. Установка в иерархию /usr/local
3. Установка в иерархию /usr
Важно не путать для чего какая нужна и не допускать бардака.
Пакеты, считаю, нужно собирать, когда поразумевается распространение или тестирование в составе софта дистрибутива.
Когда нужно что-то установить по быстрому, на «посмотреть», установить новую версию, вполне считаю допустимым сделать так как описано.
Вообще, традиционно, в UNIX есть три варианта установки, они сложились не зря, для каждого свое место.
1. Установка в домашнюю директорию
2. Установка в иерархию /usr/local
3. Установка в иерархию /usr
Важно не путать для чего какая нужна и не допускать бардака.
на посмотреть быстро… наверное, можно. тогда в этой статье нужно указать, что ./configure желательно вызывать с --prefix /some/private/writable-to-regular-user и обязательно без sudo make install. как-то так. но лучше такого не делать, даже быстро. простые пакеты просто дебианизировать а сложные так наверняка не станут, нужны будут зависимости, которые нужно либо ставить из таких же tar.gz так же криво, или мешать самосборы с системными.
В том-то и дело, что этот вариант не мешает самосборный софт с системным, а вот если пакетизировать, то мешает. В случае упаковки в пакеты нужно более тщательно тестировать и тратить больше времени, возможны конфликты имен с системным. Времени понадобится больше. Нужно самому решать, стоят ли этого затраты времени.
так уж получилось, что по политике дебиана в /usr/local не должно быть программ. Это так, просто к сведению.
www.debian.org/doc/manuals/reference/ch12.en.html#_compile_and_install_a_program
Debian does not touch files in "/usr/local/" or "/opt". So if you compile a program from source, install it into "/usr/local/" so it will not interfere with Debian.
Debian does not touch files in "/usr/local/" or "/opt". So if you compile a program from source, install it into "/usr/local/" so it will not interfere with Debian.
первый раз про такое слышу, что это за политика такая, можно ссылку?, всегда думал что там может быть что угодно в том числе и программы
Я все, что из исходников ставлю в /opt. Если надо удалить, то просто rm -rf /opt/каталог.
С xstow получается
Преимущества: xstow раскладывает ссылки по тем директориям, в которых другой софт и другие админы ожидают их увидеть. Да еще и пути и ld.so настроен на эти же директории.
В случае же изменения версии софта, если вам нужно быстро поменять версию:
Если что-то не так, xstow очень понятно жалуется. Если забли сделать xstow -D каталог, находите висящие ссылки и подчищаете ручками.
И всега порядок!
cd /usr/local/stow/ xstow -D каталог rm -rf каталог
Преимущества: xstow раскладывает ссылки по тем директориям, в которых другой софт и другие админы ожидают их увидеть. Да еще и пути и ld.so настроен на эти же директории.
В случае же изменения версии софта, если вам нужно быстро поменять версию:
cd /usr/local/stow/ xstow -D ver-1 xstow ver-2
Если что-то не так, xstow очень понятно жалуется. Если забли сделать xstow -D каталог, находите висящие ссылки и подчищаете ручками.
И всега порядок!
мне понравилась статья, пишите ещё.
статья дискретизирует убонтоводов, вы что думаете, юниксоиды не знают про мейк-мейкинстолл??? уже десятки лет все так как описано. в статье ничего нету о анализе конфиг-лога, билд-лога. ничего о контроле над ./configure… в статье рекомендуется по неудачному билду доустанавливать зависимости а не до начала установки. для дополнительных уроков информатики начальной школы — вот это что.
В мире вообще ничего нового нет, уже несколько тысяч лет.
Статья для нычинающих. Не все ведь рождаются со знаниями дарованными свыше в голове.
Как по мне, проще глянуть в выход ./configure и посмотреть, чего оно хочет, чем заранее все собирать. Где написано, что это некошерно?
Статья для нычинающих. Не все ведь рождаются со знаниями дарованными свыше в голове.
Как по мне, проще глянуть в выход ./configure и посмотреть, чего оно хочет, чем заранее все собирать. Где написано, что это некошерно?
это некошерно если чуток подумать: на этапе ./configure, если не отслеживать зависимости, можно получить отсутствие важной зависимости и в результате получить успешный билд но без требуемого функционала. например, одно время ffmpeg вынесли в экстернал зависимость в своем svn libswscale. если собирать руками и не смотреть на зависимости — можно получить после ./configure мейкфайл без USE_SWSCALER.
Конечно, если компилируешь из исходников, за зависимости отвечаешь сам. Однако иногда надо компилировать. И я тут уже привел ссылку на документацию Дебиан. Они советуют ставить самосборный софт именно в /usr/local и гарантируют, что их менеджер пакетов туда не полезет и конфликтов с менеджером не будет.
не цепляйтесь за /usr/local, да хоть в /my-super-bin/ — удивительно, но дебиан его тоже не тронет, но смысл? вы вторгаетесь не в техническую мешанину пакетов и зависимостей а в логическую. some-lib-xxyy.tar.gz вроде как и есть, а его пакетный менеджер не видит или ./configure вроде как работает, а собранный бинарник нет.
/my-super-bin/ Не подходит по двум причинам. Не кошерное место по полиси, bin намекает, что это только бинарники.
Я уже тут писал, повторю еще раз. В UNIX три кошерных метода установки софта:
1. Установка в домашнюю директорию — Устанавливает пользователь только для себя.
2. Установка в иерархию /usr/local — Устанавливает администратор, софт уникаьный для данной машины, польуются локальные пользователи.
3. Установка в иерархию /usr — Устанавливает менеджер пакетов, может быть расшарен по сети.
Все методы законные и все настраивается так, что ни менеджер пакетов не сойдет с ума и ld.so будет работать.
Я уже тут писал, повторю еще раз. В UNIX три кошерных метода установки софта:
1. Установка в домашнюю директорию — Устанавливает пользователь только для себя.
2. Установка в иерархию /usr/local — Устанавливает администратор, софт уникаьный для данной машины, польуются локальные пользователи.
3. Установка в иерархию /usr — Устанавливает менеджер пакетов, может быть расшарен по сети.
Все методы законные и все настраивается так, что ни менеджер пакетов не сойдет с ума и ld.so будет работать.
ну тогда подробней пожалуйста о том, как менеджер пакетов убунты узнает об установке пакета в /usr/local через make install. я такого не знаю.
а про три метода для юникса — ну почитайте про пути установки в pkgsrc или в сановском /opt/sun*. так уж только три?
прошу заметить, из всех возможных методов установки пакетов в убунте вы выбрали самый извращенный, самый неадекватный этому дистрибутиву и поверхностно его описали. я рад что народ минусует меня и пишет «фмемориз» вашей заметке. знаете почему рад? такие минусующие нюбы наиграются и уйдут. но кровушки и реноме бубунте попортят. а вы молодец, в принципе знаете о чем пишите и отстаиваете свою точку зрения, но вот ориентируетесь вы на сомнительную публику в написании и на сомнительные техники администрирования системы. всем удачи.
а про три метода для юникса — ну почитайте про пути установки в pkgsrc или в сановском /opt/sun*. так уж только три?
прошу заметить, из всех возможных методов установки пакетов в убунте вы выбрали самый извращенный, самый неадекватный этому дистрибутиву и поверхностно его описали. я рад что народ минусует меня и пишет «фмемориз» вашей заметке. знаете почему рад? такие минусующие нюбы наиграются и уйдут. но кровушки и реноме бубунте попортят. а вы молодец, в принципе знаете о чем пишите и отстаиваете свою точку зрения, но вот ориентируетесь вы на сомнительную публику в написании и на сомнительные техники администрирования системы. всем удачи.
Так можно много чего придумать, есть конечно еще /opt, стоит ли рассматривать его как кошерный? Я бы скорей написал так: Некоторые фирмы используют для установки софта директорию /opt. Но вот вопрос, стоит ли ставить туда самому? Нет, пускай туда ставит установщик этих фирм.
Вы считаете, так, я иначе. В полиси написано так, как у меня. Поэтому я считаю возможным рекомендовать такой метод в подходящих случаях.
Ваш метод хорош, но слишком турдоемкий. Кстати при сбрке пакета .deb Вы в какую иерархию хотите ставить? В /usr? Вот это источник потенциальной опасности и весьма реальной.
Вы считаете, так, я иначе. В полиси написано так, как у меня. Поэтому я считаю возможным рекомендовать такой метод в подходящих случаях.
Ваш метод хорош, но слишком турдоемкий. Кстати при сбрке пакета .deb Вы в какую иерархию хотите ставить? В /usr? Вот это источник потенциальной опасности и весьма реальной.
Да конечно, нужно читать доки. Но все доки читать — жизни не хватит. Поэтому ленивые (мудрые) люди читают тогда, когда что-то идет криво.
Я так понял пост затрагивает Ubuntu и используется GUI тогда, почему не пользоваться простым Synaptic Package Manager для установки? Или хочется последние версии пакетов?
советую также посмотреть в сторону paco, на хабре про нее как то писали
Как альтернативу xstow использую paco (pacKAGE oRGANIZER). Обзор можно посмотреть тут.
НЛО прилетело и опубликовало эту надпись здесь
За три года на Ubuntu ни разу ничего не ставил из исходников. Просто все самое новое уже есть либо в репах, либо в дебах. :) До этого в suse регулярно компилил.
Да, есть такая тенденция, все меньше и меньше приходится ставить мимо репозитариев. Но бывает и ставлю. Вот мой /usr/local/stow:
eik-admin emacs-escreen emacs-html-helper-mode emacs-psvn mc-4.6.3 python-cherrypy3 skype-static-2.0.0.72
НЛО прилетело и опубликовало эту надпись здесь
вообще считаю хорошим тоном при промышленном использовании дистрибутива создавать собственную ветку портов/пакаджей с системой автосбора и получать на выходе пакеты для родного пакетного менеджера, с помощью которого и обслуживаемого.
не вижу смысла разводить десяток пакетных менеджеров и поэтому ненавижу всякие cpan'ы, pear'ы и т.д. а уж описанный тут xstow совсем жесть. но впрочем кому что нравится.
не вижу смысла разводить десяток пакетных менеджеров и поэтому ненавижу всякие cpan'ы, pear'ы и т.д. а уж описанный тут xstow совсем жесть. но впрочем кому что нравится.
Ваш метод хорош тогда, когда у вас времени дофига и администрирование — это основное ваше занятие. А случаи как известно бывают разные. Я бы не стал применять такое сильное слово как ненависть. Вы, когда Вам нужно поставить на один компьютер какой-нибудь режим для emacs, которого нет в дистрибутиве, собираете для него пакет?
Мне кажется, что при самостоятельной сборке пакета, который ставит в /usr/, Вы сами отвечаете за конфликты и это источник опасностей.
Мне кажется, что при самостоятельной сборке пакета, который ставит в /usr/, Вы сами отвечаете за конфликты и это источник опасностей.
"… когда у вас времени дофига и администрировани...", — в моему псто ключевое слово «промышленном», это означает что требования к ПО не могут быть удовлетворены «готовыми» продуктами и для каких-то целей (не устраивают опции с которыми скомпилировано в репозитарии, не устраивает версия, нужно наложить собственный патч или что-то еще) требуется собственная сборка программы. случаи, да, бывают разные. никто не говорил что для 15 минутного всандаливания под пиво товарищу из соседнего офиса линуфрюкса требует обязательной самосборки пакетов.
«Я бы не стал применять такое сильное слово как ненависть.», — дело твое, нынче модно быть толлератным ко всякой гомосятине. подчеркну еще раз _НЕНАВИЖУ_ цпаны, пиры и прочий шлак. у меня на это есть причины, которые вобщем-то очевидны.
«Вы, когда Вам нужно поставить на один компьютер какой-нибудь режим для emacs, которого нет в дистрибутиве, собираете для него пакет?» — я не пользуюсь емакс. на самом деле эта ваша жизненная ситуация для меня не знакома и не только потому что я не пользуюсь емаксом. просто вот как-то у меня не было такого что ради того чтобы получить программу с нужными опциями надо было заморачиваться. видно оттого что я любитель *bsd и archlinux.
«Мне кажется…… источник опасностей.» — мне кажется надо думать головой. и никаких источников опасности и паранои.
«Я бы не стал применять такое сильное слово как ненависть.», — дело твое, нынче модно быть толлератным ко всякой гомосятине. подчеркну еще раз _НЕНАВИЖУ_ цпаны, пиры и прочий шлак. у меня на это есть причины, которые вобщем-то очевидны.
«Вы, когда Вам нужно поставить на один компьютер какой-нибудь режим для emacs, которого нет в дистрибутиве, собираете для него пакет?» — я не пользуюсь емакс. на самом деле эта ваша жизненная ситуация для меня не знакома и не только потому что я не пользуюсь емаксом. просто вот как-то у меня не было такого что ради того чтобы получить программу с нужными опциями надо было заморачиваться. видно оттого что я любитель *bsd и archlinux.
«Мне кажется…… источник опасностей.» — мне кажется надо думать головой. и никаких источников опасности и паранои.
Для каждого случая — свой инструмент. Когда начинающим рекомендуют по каждому чиху собирать пакеты и устанавливать их в систему пакетным менеджером, это явный перебор, к тому же потенциально опасный.
Это Волюнтаризм! (С) Кавказская пленница.
Я вот пользуюсь вот этим молотком (xstow) для забивания гвоздей. Считаю его вполне адекватным своим задачам инструментом.
Это Волюнтаризм! (С) Кавказская пленница.
Я вот пользуюсь вот этим молотком (xstow) для забивания гвоздей. Считаю его вполне адекватным своим задачам инструментом.
Поддерживаю. Если используешь debian-based то лучше следовать debian-way, пользуешь gentoo, то логично использовать gentoo-way, а тут на примере Дебиан показывается не пойми-какой-вей или попробуй-те-такой-вей который изначально подойдет только для собственных LFS, так как в остальных случаях нарушает логику работы менеджеров пакетов/исходников/чего-то-там еще в конкретно взятой системе. т.е. просто глупо начинать плодить сущности.
Только что приводил ссылку из Дебиан полиси. Это и есть кошерный Дебиан-вэй для самосборного софта. И как раз именно такой способ НЕ НАРУШАЕТ логику работы менеджера пакетов.
Еще раз привожу цитату и ссылку.
www.debian.org/doc/manuals/reference/ch12.en.html#_compile_and_install_a_program
Debian does not touch files in "/usr/local/" or "/opt". So if you compile a program from source, install it into "/usr/local/" so it will not interfere with Debian.
Еще раз привожу цитату и ссылку.
www.debian.org/doc/manuals/reference/ch12.en.html#_compile_and_install_a_program
Debian does not touch files in "/usr/local/" or "/opt". So if you compile a program from source, install it into "/usr/local/" so it will not interfere with Debian.
«НЕ НАРУШАЕТ ЛОГИКУ», — это такая очевидная мелочь, что прямо даже как-то смешно. любой идиот понимает что надо ставить свои горепрограммки в отдельный каталог. рискну предположить что оно и /ololorealne каталог не будет трогать. только почему то мне от этого не легче когда речь заходит действительно о менеджменте пакетов.
собери туда кучку библиотек и программы залинкованные на них, а потом замени одну из десятка программ на другую версию, а другие пять удали. вот так, за 60 секунд и чтоб шлака не осталось, и, желательно, избежать простоя сервиса, который предоставляет программа подлежащая замене версии. (вполне себе вариант при работе по апгрейду nginx и сопуствтующих программ)
всегда люблю приводит этот пример на прожжоных линуксятнигов-гуру-шлакварьщиков убежденных в том что «вот он юниксвей — собери все в одну кучу».
вы вольны поступать как хотите, нравится вам так, пожалуйста. я вас ни к чему не принуждаю. я просто высказываю мнение. а я за такой «юниксвей» бью линейкой по пальцам.
собери туда кучку библиотек и программы залинкованные на них, а потом замени одну из десятка программ на другую версию, а другие пять удали. вот так, за 60 секунд и чтоб шлака не осталось, и, желательно, избежать простоя сервиса, который предоставляет программа подлежащая замене версии. (вполне себе вариант при работе по апгрейду nginx и сопуствтующих программ)
всегда люблю приводит этот пример на прожжоных линуксятнигов-гуру-шлакварьщиков убежденных в том что «вот он юниксвей — собери все в одну кучу».
вы вольны поступать как хотите, нравится вам так, пожалуйста. я вас ни к чему не принуждаю. я просто высказываю мнение. а я за такой «юниксвей» бью линейкой по пальцам.
это одна из тех статей, которая сбивает людей столку, особенно новичков.
убунту — это система с пакетным менеджментом, поэтому софт нужно ставить в порядке убывания «правильности» так
1) репозитории — это убунту-way
2) через deb пакеты
3) из исходников создавать deb пакеты, используя
./configure
make
sudo checkinstall.
в дальнейшем следующий deb хотя бы корректно заменит предыдущий
4) очень не рекомендуется из исходников ./configure && make install
мое мнение на этот счет подробно forum.ubuntu.ru/index.php?topic=42599.0
убунту — это система с пакетным менеджментом, поэтому софт нужно ставить в порядке убывания «правильности» так
1) репозитории — это убунту-way
2) через deb пакеты
3) из исходников создавать deb пакеты, используя
./configure
make
sudo checkinstall.
в дальнейшем следующий deb хотя бы корректно заменит предыдущий
4) очень не рекомендуется из исходников ./configure && make install
мое мнение на этот счет подробно forum.ubuntu.ru/index.php?topic=42599.0
Знаете, есть полиси, в котором ясно написано, какие программы, в каких случаях и куда ставить. Это надо понимать, что, когда, куда и в каких случаях. Я уже тут писал несколько раз. Вы считаете, что лучше ставить из пакетов и только из пакетов. Я по другому. Мое мнение, оно не просто так, оно в соответствии с полиси. Порядок путей установки софта по приоритетам:
1. Из пакетов. Пакетным менеджером. Если есть нужный софт нужной версии.
2. Из исходников в директорию /usr/local путем описанным в статье. Если нужно поставить софт, которого нет в дистрибутиве, версию, которой нет в дистрибутиве. Самодельный софт.
3. В домашнюю директорию. Свой самодельный софт, софт которым пользуется только один пользователь, если нет прав админа на машине.
Пример случая N2. Когда устанавливать в /usr/local. Я разрабатываю софт. Мне нужен вебсервер на Python — CherryPy 3.1, В дистрибутиве есть CherryPy python-cherrypy 3.0.
Что лучше, установить в /usr/local, или собрать пакет и установить менеджером пакетов. Однозначно в этом случае лучше в /usr/local. Если собирать пакет, мне придется отвечать за зависимости и не факт, что это будет легко. Причем вылезти конфликт может в самом неожиданном месте.
Когда нужно собирать пакет? Когда вы собираетесь распространять его. Но тогда Вы должны проверить перед сборкой пакета зависимости и возможные конфликты. И не факт, что это будет легко и Вы сможете разрулить конфликты без общения с другими мэйтенерами пакетов.
1. Из пакетов. Пакетным менеджером. Если есть нужный софт нужной версии.
2. Из исходников в директорию /usr/local путем описанным в статье. Если нужно поставить софт, которого нет в дистрибутиве, версию, которой нет в дистрибутиве. Самодельный софт.
3. В домашнюю директорию. Свой самодельный софт, софт которым пользуется только один пользователь, если нет прав админа на машине.
Пример случая N2. Когда устанавливать в /usr/local. Я разрабатываю софт. Мне нужен вебсервер на Python — CherryPy 3.1, В дистрибутиве есть CherryPy python-cherrypy 3.0.
Что лучше, установить в /usr/local, или собрать пакет и установить менеджером пакетов. Однозначно в этом случае лучше в /usr/local. Если собирать пакет, мне придется отвечать за зависимости и не факт, что это будет легко. Причем вылезти конфликт может в самом неожиданном месте.
Когда нужно собирать пакет? Когда вы собираетесь распространять его. Но тогда Вы должны проверить перед сборкой пакета зависимости и возможные конфликты. И не факт, что это будет легко и Вы сможете разрулить конфликты без общения с другими мэйтенерами пакетов.
Мне кажется не лишнее упомянуть что в убунте легко сделать пакет, и вопросы с установкой/удалением исчезнут.
Всего-то
mkdir -p куда-то/DEBIAN
touch куда-то/DEBIAN/control
make DESTDIR=куда-то install
dpkg-build -build куда-то
и пакет есть ;)
Всего-то
mkdir -p куда-то/DEBIAN
touch куда-то/DEBIAN/control
make DESTDIR=куда-то install
dpkg-build -build куда-то
и пакет есть ;)
Бабах и конфликтует с другим софтом. Не все, что легко — хорошо.
Если собрано на текущей машине, то с чего бы????
Как с чего? Вы установили софт не прожедший процедуру проверки зависимостей/конфликтов Debian/Ubuntu в иерархию /usr. Теперь устанавливаете какой-то совсем другой софт пакетным менеджером. И у Вас внезапно конфликт имен. Т.е. два файла, из Вашего пакета и вновь устанавливаемый имеют одно и то же имя. Или конфликт зависимостей.
Я уже три раза к полиси разных граждан отсылал, там как раз про это написано.
Вообще размещение файлов дело наживное, абсолютно четких границ, скажем заданных в single unix guide, нет. В каких-то дистрибутивах есть какие-то предпочтения, но это только предпочтения. Есть деление по типу комманд (системные и нет). Есть рекомендации по размещению библиотек в гибридных системах типа (x86/x86_64), которые достаточно часто нарушаются.
Вы предлагаете использовать несколько менеджеров пакетов, что вообще говоря совсем нехорошо.
Вы предлагаете использовать несколько менеджеров пакетов, что вообще говоря совсем нехорошо.
Не вижу другого приемлемого решения. Менеджер пакетов дистрибутива и иерархия /usr — ИМХО не годится по приведенным мною неоднократно причинам. Полиси за меня.
Какие будут Ваши доказательства? (С) Красная жара.
Какие будут Ваши доказательства? (С) Красная жара.
Я не говорю, что надо обязательно устанавливать и /usr, это дело, в основном, личных предпочтений, но до тех пор, пока не захочется делиться софтами с другими, вот тут полиси важно как никогда.
Менеджеру пакетов, в принципе, все равно куда распаковывать, от него требуется знать что установлено для последующего удаления или обновления. Более провинутые варианты могут что-то делать с зависимостями.
Совсем по-другому обстоит дело когда требуется иметь разные наборы библиотек и комманд, но это совсем не для новичков.
Менеджеру пакетов, в принципе, все равно куда распаковывать, от него требуется знать что установлено для последующего удаления или обновления. Более провинутые варианты могут что-то делать с зависимостями.
Совсем по-другому обстоит дело когда требуется иметь разные наборы библиотек и комманд, но это совсем не для новичков.
НЛО прилетело и опубликовало эту надпись здесь
Имхо в pkg-based дистрибутивах надо собирать пакет из исходников — и тогда проблема контроля версий, контроля файлов — начинает отсутствовать как факт.
Проблема 1 — полная фигня. Раздули непонятно что из того, что можно решить одной командой, уж хотя бы man'ы почитали, чесслово.
#apt-get build-dep
Работает, если в sources.list прописан хотя бы один deb-src-репозитарий и в нём есть сырцы собираемого пакета. Намного быстрее и удобнее.
PS Кромер xstow и paco есть ещё ipkg.
#apt-get build-dep
Работает, если в sources.list прописан хотя бы один deb-src-репозитарий и в нём есть сырцы собираемого пакета. Намного быстрее и удобнее.
PS Кромер xstow и paco есть ещё ipkg.
*#apt-get build-dep имя_собираемого_пакета
PS Ох уж этот парсер
PS Ох уж этот парсер
Способом, описанным в статье собираются программы, которых нет в репозиториях, поэтому apt-get build-dep не подойдёт.
Скажите, вы часто устанавливаете такие программы? Я видел такое всего один раз.
PS Если в репозитариях нет бинарной версии — это не значит, что в репозитария нет исходных кодов.
PS Если в репозитариях нет бинарной версии — это не значит, что в репозитария нет исходных кодов.
Вопрос интересный. Попробуем ответить.
Пока был на стабильной ветке Дебиана, такая необходимость возникала часто, устанавливал программы более свежих версий, чем в дистрибутиве.
С переходом на Убунту, необходимость уменьшилась, хотя и не исчезла совсем.
Что устанавливаю теперь? Как и тогда, кое чего нет в дистрибутиве, кое-что нужно свежее, чем в дистрибутиве.
Вот мой текущий список программ, установленных из исходников:
Пока был на стабильной ветке Дебиана, такая необходимость возникала часто, устанавливал программы более свежих версий, чем в дистрибутиве.
С переходом на Убунту, необходимость уменьшилась, хотя и не исчезла совсем.
Что устанавливаю теперь? Как и тогда, кое чего нет в дистрибутиве, кое-что нужно свежее, чем в дистрибутиве.
Вот мой текущий список программ, установленных из исходников:
| eik-admin | Мои админские скрипты | | emacs-escreen | Нет в дистрибутиве | | emacs-html-helper-mode | Нет в дистрибутиве | | emacs-psvn | Нет в дистрибутиве | | mc-4.6.3 | Свежее, чем в дистрибутиве | | python-cherrypy3 | Свежее, чем в дистрибутиве | | skype-static-2.0.0.72 | Нет в дистрибутиве |
Да, кроме этого есть еще несколько пэкиджей для emacs, установленных в домашней директории.
Вы не поняли. Для того, чтобы эта команда сработала нужен всего лишь список необходимых пакетов из deb-src-репозитария. Если нет в просто репозитари пакета, то это не означает, что нет его в репозитарии исходников. И версия там чаще всего значения абсолютно не имеет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Linux: Установка программ не входящих в дистрибутив при помощи менеджера xstow