From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <44159E9E.2050403@altlinux.org> Date: Mon, 13 Mar 2006 19:32:30 +0300 From: Mikhail Yakshin User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050905) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] ruby-rake =?KOI8-R?Q?=C9_gems?= References: <4415833C.2050604@altlinux.org> <20060313144354.GI6144@pc152.sam-solutions.net> <44158E9E.6010108@altlinux.org> <20060313154153.GK6144@pc152.sam-solutions.net> In-Reply-To: <20060313154153.GK6144@pc152.sam-solutions.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2006 16:32:31 -0000 Archived-At: List-Archive: List-Post: Kirill A. Shutemov wrote: >>Технических подробностей и нет. В ruby нет версионирования файлов, >>правильно? Поэтому просто так программа не может потребовать файл >>такой-то версии такой-то, как тут например (см. выше) - требуется rake >> >>>= 0.6.2. >> >>Единственный вариант, который я вижу - ломать gems на предмет смотрения >>в базы RPM - думаю, это совсем крайний случай. > > В базу лесть не обязательно, достаточно дёрнуть rpmquery. Хотя тоже > костыль. Ну, да, согласен... >>>2. Собирать не из gems. >> >>Всё ломать на тему отрывания gems - малореально, очень сложно и очень >>bug-prone. Мы не сможем его оттестировать в достаточной мере, и каждый >>апдейт будет превращаться в кошмар - все придется по сути переделывать >>заново. Опять же - потом по сути лишаем юзера любой поддержки, кроме >>нашей. Всё, что не пройдет через наши руки - будет невозможно установить. >> >>У меня есть, как ни банально - предложение решить все третьим вариантом: >>вернуть сборку ruby-rake из gems и не трогать ее. > > У меня, есть ещё один вариант. Имеет ли смысл вообще оборачивать в rpm > gem'ы? Может просто собрать rubygems и успокоиться. Всё остальное > пользователь вытянет с помощью самого gems. gem сам по себе - отдельный package manager, а не некая панацея. Допустим, у меня абсолютно изолированная система, не имеющая доступа в интернет или просто возможности качать несколько мегов пакетов. Так мне придется сделать: Принести локально копию Сизифа, поставить rubygems. Попытаться сделать gem update, понять, что списки пакетов даже я не скачаю, дойти до машины с интернетом, скачать их там, принести файликом. Поставить наконец-таки этот список пакетов вручную, сделать gem install rails с некими опциями, понять, что скачать нельзя, взять (а ля offline apt) список пакетов, отнести его опять же на другой компьютер, скачать их там, принести-поставить. Последние несколько шагов, возможно, придется повторить в несколько итераций. А если еще и пакеты в процессе несения успеют проапдейтится - вообще начинать все с начала. В случае наличия пакетов в Сизифе - прихожу, ставлю локальную копию Сизифа, говорю apt-get install ruby-rails - и работаю. Думаю, некий смысл в этом есть, нет? > Можно ещё отделить собраные из gems пакеты от собраных из tar, как > предложил raorn@. Да, вариант. Итого, подвожу черту. Предложены варианты (плюсы и минусы рискну описать со своей point of view): 1. Форкнуть все хозяйство ruby и иметь 2 варианта: с gem и без. Плюсы: никто никому не мешает, никто ни с кем не ругается, все работает. Минусы: куча работы, которая еще и дублируется. 2. Сделать в gems поддержку смотрения на пакеты в RPM. Плюсы: теоретически эту проблему решим. Минусы: не факт, что дальше не всплывет что-то еще, для чего критичны именно rake из gem; несистемность подхода, просто подпорка для лечения симптома. 3. Собирать не из gems. Плюсы: все идеально, все работает, все идеологически прямо. Минусы: малореально; дикое количество работы и стремящееся к бесконечности (~сложность написания всего заново) сложность поддержки. 4. Собрать rake и все, что потребуется по дороге с gems. Плюсы: будет работать, минимальные телодвижения. Минусы: остается спорность неких моментов, относящихся к FHS; raorn@ приводил пример с require vs require_gem; 5. Выкинуть все, что относится к rubygems как таковому из Сизифа, кроме самого менеджера пакетов. Плюсы: отдельно имеем 2 пакетные системы, все точно будет работать. Минусы: нарушаем целостность дистрибутива, с большой вероятностью получаем полный зоопарк неподдерживаемых файлов; примерный сценарий счастья, которое можно получить - описан выше. Сколько у нас заинтересованных лиц и среди заинтересованных - кто за какой способ решения вопроса? > И вообще, тебе как мэйнтейнеру rubygems следовало бы пинать upstream. > Тогда может быть мы когда-нибудь получим, что-то пригодное к > использованию в package-based дистрибутивах. Сейчас оно таковым не > является. Да объясни, почему не является-то? Все их используют - а мы чем такие уникальные? -- WBR, Mikhail Yakshin AKA GreyCat