Установить старую версию пакета subversion

Добрый день.

Заказчик дал указания по разворачиванию проекта. Указал, что версия svn-клиента должна быть не выше 1.6. У меня стоит subversion-1.8.11.

Собственно, вопрос такой: какие мои действия должны быть, чтобы (хотя бы) поставить старую версию? В идеале - поставить их рядышком и переключать при помощи eselect ;)
Пробовал маскировать в package.mask версию >1.7 и добавлять оверлей chromiumos. Оттуда ставится dev-util/subversion, только мне кажется, это что-то не то: команды svn после этого нет.
Честно, с svn сталкиваюсь впервые. Может вообще что-то не то делаю?

Заранее благодарю за ответы!

Вот отсюда скачиваешь ebuild

Вот отсюда скачиваешь ebuild версии 1.6.17-r7, помещаешь в локальный оверлей, оттуда же из директории files скачиваешь нужные патчи и прочие файлы, помещаешь их в директорию files, далее делаешь digest по ebuild`у и ставишь эту версию.

Удачи.

далее делаешь digest по

далее делаешь digest по ebuild`у
и с огромной вроятностью обламываешся :)

П.С гента для установки г... мамонта предназначена крайне плохо.

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Цитата:и с огромной

Цитата:
и с огромной вроятностью обламываешся :)

С чего это вдруг? Дистрибутив исходников будет скачан с официального сайта, патчи есть в CVS. Как минимум digest он выполнит.

Если не соберётся, то уже нужно смотреть почему и, возможно, указывать дополнительные патчи или менять сам ebuild и процедуру сборки, но последнее вряд ли.

Граф обычно не сходится, в

Граф обычно не сходится, в данном случае наврняка где то в районе неона.

П.С дигест мобно сделать над спринципиально несобираемум пакетом, это ничего не меняет.
П.П.С И тц нужен пакет, а не дигест от ебилда ;)

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

slepnoga написал(а): П.С

slepnoga написал(а):
П.С дигест мобно сделать над спринципиально несобираемум пакетом, это ничего не меняет.

Стоп, ты сказал:

slepnoga написал(а):
далее делаешь digest по ebuild`у
и с огромной вроятностью обламываешся :)

Из этого следует, что ты уже сомневаешься в самой возможности digest.

Цитата:
П.П.С И тц нужен пакет, а не дигест от ебилда ;)

А вот после digest`а он может попробовать собрать пакет нормальным способом:

emerge -av =dev-vcs/subversion-1.6.17-r7

Может собраться, а может и нет. Но попробовать стоит. Да и тебе, прежде чем начал высказывать беспочвенные предположения, не спорю, что ты встречался когда старые ebuild`ы не собирались ввиду наличия в современной системе других версий компонентов, ну или попросту строишь доводы, которые впрочем могут оказаться верными. Но опять же в каждой ситуации нужно всё проверять. Если у ТС соберётся subversion из ebuild`а - хорошо, нет - в таком случае нужно искать причину и разбираться.

/

slepnoga написал(а):
гента для установки г... мамонта предназначена крайне плохо.

Причём тут гентушечка?
Проблема полностью локализуется в области математики (сходимость и условия решения задачи построения графа зависимостей).

:wq
--
Live free or die

.

ТС сказал же, что необходим клиент svn.

Далее вопросы:

tetramin написал(а):
У меня стоит subversion-1.8.11.

Он зачем-то нужен? при:
1)

tetramin написал(а):
Честно, с svn сталкиваюсь впервые.

и:
2)

tetramin написал(а):
В идеале - поставить их рядышком и переключать при помощи eselect

В последних версиях было добавлено много для того, чтобы оставить svn на плаву. Точнее он был переориентирован на офисный планктон с его любимыми документами в MSOffice и которому нет необходимости работать с частями рабочей копии без участия сервера.

На сколько я проводил эксперименты новые версии нормально работают со старыми серверами. Поэтому можно проверить адекватность требований:

tetramin написал(а):
Указал, что версия svn-клиента должна быть не выше 1.6.

В итоге можно:
или 1) попытаться поставить в систему только старый svn-клиент. При этом придется побороться с флагами, отключая в других пакетах зависимость от svn.
или 2) осторожно поставить svn в домашний каталог того пользователя, который будет работать с проектами (совсем не факт, что надо работать с проектом от своего пользователя). А svn-1.8 будет доступен остальным пользователям.

PS. Установка пакета в систему нужна для сервисов, и то можно что-то придумать на ниве виртуализации.

Поставил в домашнюю папку юзера

Заказчик говорит, что могут возникнуть проблемы и не получится ничего выгрузить.
Поставил в домашнюю папку юзера путём обычной сборки (./configure и т. д.). В итоге пакет полностью не проинсталлировался (make install), остановился на попытке (от имени юзера) записать файл /usr/lib64/apache2/modules/mod_dav_svn.so - естественно не хватило прав. Это к лучшему, в случае, если и была вероятность поломать всю свою систему, то это хоть как-то умерит пыл...
Теперь вот какой вопрос: в папке юзера теперь есть папка с этой версией subversion, в которой лежит папка bin со всеми бинарниками. Мне будет их достаточно для загрузки, выгрузки и вообще работы с этим svn-репозиторием?
Может вообще есть альтернативный вариант для работы с svn-репозиториями?

Могут возникнуть проблемы (то

Могут возникнуть проблемы (то есть мы типа перестрахуемся) или же пробовали - и проблемы уже возникали? В первом случае - гнать такого заказчика. Ибо самодур.

Пользуясь моментом, хочу передать привет друзьям, которые также пользуются "Моментом"

.

Я бы поступил следующим образом.

Используя старый ebuild и утилиту ebuild получил бы пропатченую версию исходников:
(На примере 1.8.10)

#ebuild /usr/portage/dev-vcs/subversion/subversion-1.8.10.ebuild prepare
 * subversion-1.8.10.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...                                  [ ok ]
 * checking ebuild checksums ;-) ...                                                               [ ok ]
 * checking auxfile checksums ;-) ...                                                              [ ok ]
 * checking miscfile checksums ;-) ...                                                             [ ok ]
>>> cfg-update-1.8.2-r1: Checksum index is up-to-date ...
 * 
 * SVN_BDB_VERSION variable isn't set. You can set it to enforce using of specific version of Berkeley DB.
 * Using: Berkeley DB 4.8
 * 
>>> Unpacking source...
>>> Unpacking subversion-1.8.10.tar.bz2 to /tmp/portage/dev-vcs/subversion-1.8.10/work
>>> Source unpacked in /tmp/portage/dev-vcs/subversion-1.8.10/work
>>> Preparing source in /tmp/portage/dev-vcs/subversion-1.8.10/work/subversion-1.8.10 ...
 * Applying subversion-1.5.4-interix.patch ...                                                     [ ok ]
 * Applying subversion-1.5.6-aix-dso.patch ...                                                     [ ok ]
 * Applying subversion-1.8.0-hpux-dso.patch ...                                                    [ ok ]
 * Applying subversion-fix-parallel-build-support-for-perl-bindings.patch ...                      [ ok ]
 * Applying subversion-1.8.1-revert_bdb6check.patch ...                                            [ ok ]
 * Applying subversion-1.8.9-po_fixes.patch ...                                                    [ ok ]
 * Running autoconf ...                                                                            [ ok ]
 * Running elibtoolize in: subversion-1.8.10/
 *   Applying target-nm/2.4.2 patch ...
 * Running elibtoolize in: subversion-1.8.10/build/
 *   Applying portage/1.2.0 patch ...
 *   Applying sed/1.5.6 patch ...
 *   Applying as-needed/2.4.2 patch ...
>>> Source prepared.

Далее, забрал бы себе себе содержимое ${PORTAGE_TMPDIR}/portage/dev-vcs/subversion-1.8.10/work/subversion-1.8.10 (и не забыл бы сменить владельца на своего).

Прочитав README, INSTALL и вывод

configure --help

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

$configure --help
...
By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.
...

Создал бы каталог ~/svn, который бы передал бы --prefix=${HOME}/svn

И только тогда

configure $(MY_CONFIG_OPTIONS)
make $(MY_MAKE_OPTIONS)
make install

Останется только внести путь в PATH пользователя и научить исполнимый файл искать в нужном месте библиотеки.

------------------------

Судя по

tetramin написал(а):
записать файл /usr/lib64/apache2/modules/mod_dav_svn.so

ничего из указанного выше проделано не было.

-----------------------

Думаю, что существует вероятность, что можно было бы воспользоваться

USE="-all_server_options" ROOT="/home/username/svn" emerge =dev-vcs/subversion-1.6.x

при subversion-1.6.x расположенном в локальном оверлее.

-----------------------

PS. Вы админ, разработчик? Это же базовые основы установки пакетов *nix. Странно, почему они Вам не известны.
PPS. Да много за нас делает emerge, а не только предоставляет возможность иметь скринсейвер с процессом сборки и запускать обогреватель помещения :) .

Что делал: Попробовал

Что делал:

Попробовал это:

kostik87 написал(а):
Вот отсюда скачиваешь ebuild версии 1.6.17-r7, помещаешь в локальный оверлей, оттуда же из директории files скачиваешь нужные патчи и прочие файлы, помещаешь их в директорию files, далее делаешь digest по ebuild`у и ставишь эту версию.

При попытке выполнить

# ebuild /usr/local/portage/dev-vcs/subversion/subversion-1.6.17-r7.ebuild manifest

Получаю ответ:

* ERROR: dev-vcs/subversion-1.6.17-r7::x-portage failed (depend phase):
 *   EAPI=3 is not supported by perl-module.eclass
 * 
 * Call stack:
 *                     ebuild.sh, line 550:  Called source '/usr/local/portage/dev-vcs/subversion/subversion-1.6.17-r7.ebuild'
 *   subversion-1.6.17-r7.ebuild, line  11:  Called inherit 'autotools' 'base' 'bash-completion' 'db-use' 'depend.apache' 'elisp-common' 'flag-o-matic' 'java-pkg-opt-2' 'libtool' 'multilib' 'perl-module' 'python' 'user'
 *                     ebuild.sh, line 280:  Called __qa_source '/usr/portage/eclass/perl-module.eclass'
 *                     ebuild.sh, line  80:  Called source '/usr/portage/eclass/perl-module.eclass'
 *            perl-module.eclass, line  40:  Called die
 * The specific snippet of code:
 *              die "EAPI=${EAPI} is not supported by perl-module.eclass"
 * 
 * If you need support, post the output of `emerge --info '=dev-vcs/subversion-1.6.17-r7::x-portage'`,
 * the complete build log and the output of `emerge -pqv '=dev-vcs/subversion-1.6.17-r7::x-portage'`.
 * Working directory: '/usr/lib64/python2.7/site-packages'
 * S: '/var/tmp/portage/dev-vcs/subversion-1.6.17-r7/work/subversion-1.6.17'

Соответственно, у меня нет ебилда 1.6.17-r7 в локальном оверлее.

Что это значит и как бороться: EAPI=3 is not supported by perl-module.eclass ?

Я бы и рад, чтобы вот так, как на примере 1.8.10, да только не всё так просто. Ведь у меня нет "старого" ебилда от версии 1.6.17. Пробовал скачать исходник от 1.6.9, конечно же использовал prefix при configure.

______________________________________
P.S. Прошу сильно не пинать - я ведь только изучаю установку пакетов, и читать не отказываюсь.
P.P.S Уже начинаю склоняться в сторону виртуализации... Не знаю, какое решение лучше и изящнее.

.

tetramin написал(а):
При попытке выполнить

# ebuild /usr/local/portage/dev-vcs/subversion/subversion-1.6.17-r7.ebuild manifest

Получаю ответ:

* ERROR: dev-vcs/subversion-1.6.17-r7::x-portage failed (depend phase):
 *   EAPI=3 is not supported by perl-module.eclass
...

Соответственно, у меня нет ебилда 1.6.17-r7 в локальном оверлее.

То ли на удачу, то ли на беду - результат

#ebuild /usr/portage/dev-vcs/subversion/subversion-1.6.17-r7.ebuild prepare

https://drive.google.com/file/d/0B-l9it5XeZaHaFdlT3J6Qkp6VUE/view?usp=sharing

.

Вот поизвращался дальше. %)
Собрал до стадии ebuild install:
https://drive.google.com/file/d/0B-l9it5XeZaHdV9VZFVoQk9LS3c/view?usp=sharing

Если распаковать содержимое image в домашний каталог как svn-1.6.17, то у меня создал репозиторий версии 1.6

LD_LIBRARY_PATH="/home/user/svn-1.6.17/usr/lib64" /home/user/svn-1.6.17/bin/svnadmin create /home/user/tmp/repos
LD_LIBRARY_PATH="/home/user/svn-1.6.17/usr/lib64" /home/user/svn-1.6.17/bin/svn import /home/user/aaa_src file:///home/tmp/repos/aaa
LD_LIBRARY_PATH="/home/user/svn-1.6.17/usr/lib64" /home/user/svn-1.6.17/bin/svn co file:///home/tmp/repos/aaa

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

Что-то я всё равно делаю не так.

Но я не понимаю, что же именно я делаю не так...

Команда:

#ebuild /usr/portage/dev-vcs/subversion/subversion-1.6.17-r7.ebuild prepare

Говорит, что ей нужен digest.

Сделать дайджест тоже не могу.
В общем забил пока. Начал смотреть в сторону виртуализации.

Я понимаю, что всё это от того, что мною недостаточно досконально изучен процесс сборки в gentoo. Ткните, пожалуйста, носом в литературу. Желательно на русском, конечно.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".