Разработчики openSUSE Build Service (http://open-build-service.org/) (OBS) объявили (http://news.opensuse.org/2011/05/26/opensuse-renames-obs/) о переименовании проекта в Open Build Service. В качестве причины указывается на то, что платформа уже давно поддерживает широкий спектр дистрибутивов и не привязана к продукту openSUSE, упоминание которого в названии сохранилось по историческим причинам. Чтобы не вводить пользователей в заблуждение и подчеркнуть отсутствие привязки к определенному дистрибутиву, вместо "openSUSE" в названии системы теперь используется слово "Open", что позволило сохранить уже вошедший в обиход акроним OBS. Разработка OBS как и прежде будет происходить под покровительством проектов openSUSE и SUSE Linux.
Кроме того, разработчики считают, что новое имя будет способствовать унификации наименований сторонних решений на базе OBS, которые теперь можно называть в соответствии с маской "XXX Open Build Service", например, активно использующие OBS проекты VideoLan и...URL: http://news.opensuse.org/2011/05/26/opensuse-renames-obs/
Новость: http://www.opennet.me/opennews/art.shtml?num=30678
> и одной командой собрать последнюю версию заданной программы в виде бинарного пакета под нужную системуа так же еще кучу зависимостей?
>> и одной командой собрать последнюю версию заданной программы в виде бинарного пакета под нужную систему
> а так же еще кучу зависимостей?Куча зависимостей к моменту сборки сама должна быть представлена уже в виде бинарных пакетов, доступных либо в дистрибутиве, для которого производится сборка, либо в том же репозитории, где производится сборка.
Собственно, даже наличие несобранных пакетов в текущем репозитории, необходимых для сборки нового пакета в общем случае гарантирует удачную сборку (если пакеты вообще соберутся), поскольку OBS собирает просто ВСЕ пакеты, а зависимости, и соответственно, порядок сборки, отслеживаются по тегам BuildRequires.
Кстати есть ещё удобные способы импорта пакетов из соседних репозитороев: можно "отпочковать" свою ветку пакета, существующего в любом доступном репозитории, либо просто импортировать такой пакет как есть. Только второй подход, иногда гораздо более удобный, чем своя ветка, не делается одним кликом через веб и требует ручной работы.
шикарный сервис
какой то мутный сервис
по старинке как то удобнее, проще и быстрее
> какой то мутный сервис
> по старинке как то удобнее, проще и быстрееА кто ЭТО юзал ? Я могу туды заливать свои src.rpm и получать готовые
рпм. Или лить можно только спеки ?
> Я могу туды заливать свои src.rpm и получать готовые рпм..src.rpm надо распаковать архиватором, и залить пофайлово. Так будет работать.
Там, правда, есть служба для автоматической закачки .src.rpm из веба и автоматической распаковки, но я ее не юзал.
А можно закачать только spec и использовать службу "Download files as specified in spec file". Естественно, для этого Source'ы в spec'е должны быть URL'ами.С некоторых пор так и делаю.
если серверов пять-десять то может и быстрее
> Система OBS позволяет организовать процесс кросс-компиляции пакетов для большинства основных дистрибутивов Linux, использующих пакеты в формате RPM или DEB, или собирать собственные дистрибутивы на основе заданной пакетной базы. Среди поддерживаемых дистрибутивов: CentOS, Debian, Fedora, Mandriva, openSUSE, SUSE Enterprise Linux, Red Hat Enterprise Linux (RHEL) и Ubuntu.Что только народ не придумает лишь бы java не изучать. Java, конечно, не предел совершенства, но кросс-компиляция не нужна. И работает что под Win что под Lin что под 64 что под 32 бита. И все одна сборка ;)
> И все одна сборка ;)Ты это народу раскажи а то они дураки и не в курсе даже.
Хотя бы тем кто делает Еклипсу :)Она есть отдельно в версии для линух и вин и отдельно для 32 и 64.
P.S. Что уже на каникулах ? ;)
Eclipse построен на SWT. SWT имеет найтивный код. Поэтому долгое время вообще 64 битного эклипса небыло. Но виновата не java.
братец, вынужден указать тебе на непонимание вопроса. использование java никак не решит вопрос различий в пакетных системах дистрибутивов.
>Что только народ не придумает лишь бы java не изучать...но кросс-компиляция не нужна. И работает что под Win что под Lin что под 64 что под 32 бита.Ужо нет. Мы, гентушнеги, и дальше предпочтём компилять софт, написанный на языках, позволяющих компилять его в нативные машинные коды. Да и, думаю, многие негентушнеги с этим тоже согласятся.
В OBS меня печалит ток то что он на suse как сервер и веб к апи работает. В остальном можно только клиент поставить.
> В OBS меня печалит ток то что он на suse как сервер
> и веб к апи работает. В остальном можно только клиент поставить.pkgsrc.org
Там можно ставить все.
Фундаментальные отличия от OBS:
- Собранные пакеты ставятся не ВСЕСТО родных, которые в /,
а дополнительно, в другое место, например в /usr/pkg (default).
- Пакетная система не нативная, а отдельная, своя.
Свои же и инструменты управления пакетами, как низкоуровневые,
так и высокоуровневые.
- Поддерживаются не только Линуксы, а вообще все, что движется.
> - Собранные пакеты ставятся не ВСЕСТО родных, которые в /,
> а дополнительно, в другое место, например в /usr/pkg (default).См. тж. критику 0install на аналогичный счёт.
>> - Собранные пакеты ставятся не ВСЕСТО родных, которые в /,
>> а дополнительно, в другое место, например в /usr/pkg (default).
> См. тж. критику 0install на аналогичный счёт.Не понял, куда смотреть?
>>> - Собранные пакеты ставятся не ВСЕСТО родных, которые в /,
>>> а дополнительно, в другое место, например в /usr/pkg (default).
>> См. тж. критику 0install на аналогичный счёт.
> Не понял, куда смотреть?http://www.opennet.me/openforum/vsluhforumID3/77309.html#29 и ниже по треду, хотя там обсуждение ещё в процессе (и мне лично весьма интересно слушать, что говорят "навстречу").
>>>> - Собранные пакеты ставятся не ВСЕСТО родных, которые в /,
>>>> а дополнительно, в другое место, например в /usr/pkg (default).
>>> См. тж. критику 0install на аналогичный счёт.
>> Не понял, куда смотреть?
> http://www.opennet.me/openforum/vsluhforumID3/77309.html#29 и ниже по треду, хотя
> там обсуждение ещё в процессе (и мне лично весьма интересно слушать,
> что говорят "навстречу").Если очень хочется потренировать "канделябр" и всех подровнять,
вываливай здесь.
Твое "критика на аналогичный счет" мне ни о чем не говорит.
Я пока не вижу ничего "аналогичного".
> Если очень хочется потренировать "канделябр" и всех подровнять,Не, не хочется.
> Твое "критика на аналогичный счет" мне ни о чем не говорит.
> Я пока не вижу ничего "аналогичного".Когда у тебя начинают размножаться места, которые могут что-то провайдить (хотя бы "общесистемное" и "местноустановленное"), резко усложняется учёт ситуаций помимо "поставить".
Из обдумывавшихся задачек на схожую тему -- раскатывание веб-софта по {вирт,}хостам.
> Когда у тебя начинают размножаться места, которые могут что-то провайдить (хотя бы
> "общесистемное" и "местноустановленное"),
> резко усложняется учёт ситуаций помимо "поставить".Нет ;-)
> Из обдумывавшихся задачек на схожую тему -- раскатывание веб-софта по {вирт,}хостам.
Насколько я вижу, для "раскатывания" веб софта
те, кто на передовой, давно уже забили на общесистемные
пакеты, и напрямую пользуются
яйцами, гемсами и прочей локальной требухой.
Это как бы звоночек дистростроителям, которые всегда не успевают
и успеть не могут в принципе, даже самые крупные.
> Насколько я вижу, для "раскатывания" веб софта
> те, кто на передовой, давно уже забили на общесистемные
> пакеты, и напрямую пользуются яйцами, гемсами и прочей локальной требухой.Мимо. Это скорее для раскатывания стеков софта, который бывает и вебовым, но именно _это_ -- не про то, когда один экземпляр софта может иметь смысл реюзать по нескольким виртхостам.
> Это как бы звоночек дистростроителям, которые всегда не успевают
> и успеть не могут в принципе, даже самые крупные.Тут как:
1) гемсы-яйтсы -- отчасти да, причём _к сожалению_ -- ни там, ни там толком не хватило опыта/мозгов/желания сделать достаточно метаданных для автоматической трансляции в нативные пакеты; по крайней мере дизайн гемсов я наблюдал и по дури/ложной скромности/перегрузке тогда не влез со своими пятью копейками (а про дизайн яйтсов слышал от хорошего знакомого, но то совсем отдельная история);
2) про конкретно веб-софт звоночек в основном к его авторам, поскольку зрелость в плане необходимости напильника при развёртывании там только-только отходит от типичного фрюниксового сишного кода пятнадцатилетней давности: например, мы с pilot@ в 2004 или около того скривились на гентушное копирование и попытались изобразить на симлинках с мультиплексированием конфига сообразно виртхосту, но без лоботомии к тому тогда годилась только TYPO3 из того, что под рукой (сейчас ещё как минимум Drupal) -- тот же phpMyAdmin, который весьма хотелось обновлять оперативно и централизованно, пришлось запиливать.То есть звоночки-то есть, но с ними тоже не всё так просто, если посмотреть повнимательней и задуматься немного.
>> Это как бы звоночек дистростроителям, которые всегда не успевают
>> и успеть не могут в принципе, даже самые крупные.
> Тут как:
> 1) гемсы-яйтсы -- отчасти да, причём _к сожалению_ -- ни там, ни
> там толком не хватило опыта/мозгов/желания сделать
> достаточно метаданных для автоматической
> трансляции в нативные пакеты; по крайней мере дизайн гемсов я наблюдал
> и по дури/ложной скромности/перегрузке тогда не влез со своими пятью копейкамиНе знаю, как там у вас гемсами, а у нас автоматика вполне присутстует.
Пример пакетирования пакета с гемсами:http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/devel/...
Кратко, понятно. А вы, видимо, свои канделябры рихтуеете ;-)
>> достаточно метаданных для автоматической[...]
> Не знаю, как там у вас гемсами, а у нас автоматика вполне присутстует.Лёш, автоматику нарисовать можно. Ты читать попробуй.
> Пример пакетирования пакета с гемсами:
[...]
> Кратко, понятно.И добавив метаданных. Вот я об этом. Этак-то и гентушники умеют.
>> Кратко, понятно.
> И добавив метаданных. Вот я об этом. Этак-то и гентушники
> умеют.Ты разговариваешь сам с собой.
P.S. Уже и гентушники ему не угодили :-)
>>> Кратко, понятно.
>> И добавив метаданных. Вот я об этом. Этак-то и гентушники умеют.
> Ты разговариваешь сам с собой.Боюсь, ты опять временно читать разучился (по крайней мере то, что мне удаётся написать).
> P.S. Уже и гентушники ему не угодили :-)
Ну почему же -- они сделали то же, что и ты показываешь, только уже довольно давно.
По-хорошему, _все_ важные метаданные (в т.ч. URL и в идеале -- категоризацию, даже если отмапив) должно быть возможно взять из gem/egg. Может быть удобнее сдублировать что-то руками, но если их там попросту недостаёт, то руками приходится _добавлять_. Потому что когда дизайнили, то к вопросу важности по крайней мере в случае rubygems подошли по-виндовому.
>>>> Кратко, понятно.
>>> И добавив метаданных. Вот я об этом. Этак-то и гентушники умеют.
>> Ты разговариваешь сам с собой.
> Боюсь, ты опять временно читать разучился (по крайней мере то, что мне
> удаётся написать).Как изъясняешься, так тебя и понимают.
>> P.S. Уже и гентушники ему не угодили :-)
> Ну почему же -- они сделали то же, что и ты показываешь,
> только уже довольно давно.Да ради бога.
> По-хорошему, _все_ важные метаданные (в т.ч. URL и в идеале -- категоризацию,
> даже если отмапив) должно быть возможно взять из gem/egg.URL-ю в тарболе делать точно нечего.
Файлу все равно, куда его положили или переместили, на основной сайт или зеркало.
Что касается остального, то эта информация должна быть доступна
*ДО* скачивания тарбола, и тому есть масса применений,
соответственно, должна быть продублирована в описании самого пакета.> Может быть удобнее сдублировать что-то руками, но если их там попросту недостаёт,
> то руками приходится _добавлять_. Потому что когда дизайнили, то к
> вопросу важности по крайней мере в случае rubygems подошли по-виндовому.Опять же, не знаю, как там у вас, а у нас за создание заготовки
для пакета на основе URL-я с заглядыванием ему внутрь отвечает pkgtools/url2pkg.
*Всего* в нем, конечно, нет, но в принципе с ненужными добавлениями руками
этот подход вполне справляется. И заглядывать, очевидно, можно не только в metainfo,
которой чаще всего просто нет.