https://yadi.sk

/0

Готовый .src.rpm пакет для Магейи:

…на тындекс-диске при живых-то Fedora COPR и OpenSUSE Build Service. Я не против тындекс-диска в принципе, но rpm-пакеты проще и удобнее ставить/обновлять из репозиториев. Блин, даже у teamviewer, Skype и VK messenger есть репозитории! К тому же, что в коппере, что в obs можно пакетить не только для Магейи.

Что неудобного в «rpm -ihv /путь/к/пакету»? В случае .src.rpm пакета, конечно, добавляется ещё «rpmbuild -ra /путь/к/.src.rpm.пакету».

И где прямая ссылка на яндекс диск? У меня там вебморда, как это из RPM обработать?

В чём проблема скачать руками? Всё равно бы пришлось копировать ссылку какому-нибудь wget'у (если не через браузер по ней качать).

В чём проблема скачать руками?

А у меня вот нет браузера нормального. Есть xterm, есть links2 – дальше что?

Твоя ссылка бесполезна, выложи хоть на фтп.

links2 хоть свежий? Свежий links умеет качать по таким ссылкам: https://drive.google.com/file/d/163-dVSI1iQKmPcKWpTdEdkZNmcN8fxon/view .

Я про то что прямые ссылки – это гуд. Не прямые ссылки – где надо или веб2.0, или регистрацию, или еще что-то такое – не гуд.

А у куда ведет прямая ссылка – дело десятое. Я выковыривал из гугл-диска прямые ссылки, из я.диска не помню уже.

Что поделать. Развитие облаков привело к тому, что они вытеснили FTP'шники с аккаунтами. 4 года назад ещё был один такой FTP'шник, но он быстро закончился.

Ну тогда хоть гит, не? Сырцы же всё равно.

Когда изо всех сил пытаешься быть олдскульным Ъ, но выкладываешь свой stuff на Я.Диске.

На github'е у меня репозиторий такого рода: https://github.com/saahriktu/mageia-pkg-dev/tree/master/без оригинальных spec... .

Кстати, надо бы мне добраться всё это пообновлять, да.

Я тоже выкладываю свои бинарники на Яндекс.Диск, и ничего. Соберу какую-нибудь фигню в виде универсального бинарника

Я тоже выкладываю свои бинарники на Яндекс.Диск

Ну значит с тобой всё понятно.

Яндекс.Диск генерирует короткие ссылки. А ты видел какие ссылки генерирует Google Drive? А их постит каждый второй...

Линуксоиды блин…. Яндекс им ссылки генерирует.

Неужели это правда не очевидно?

Что неудобного в «rpm -ihv /путь/к/пакету»?

Во-первых, /путь/к/пакету сам по себе не появится, его туда надо скачать (*). Во-вторых, rpm -ihv не разрешит зависимости твоего пакета (**). В-третьих, rpm -ihv выругается на неизвестную GPG-подпись (***). Итого, вместо двух действий для установки (***) и одного для обновления получаем минимум три (****). Спасибо, здесь не винда, не макось и не слаква.

И это не говоря о возможностях, даваемых коппером и билдсервисом сборщику пакетов.

(*) Да, rpm(1), yum(1) и dnf(1) принимают url как аргумент, но непрямой ссылой на тындекс-диск они подавятся.
(**) Да, у данного пакета нету ни зависимостей, ни подписи, но я даю обобщенный ответ.
(***) Первое действие — подключение репозитория, второе — собственно установка. Пакеты из свежеподключаемых COPR-репозиториев ставятся в две команды.
(****) Скачать пакет, добавить GPG-ключ, установить. Повторить для отдельно лежащих зависимостей.

rpmbuild -ra /путь/к/.src.rpm.пакету

Ты хотел сказать mock /путь/к/.src.rpm.пакету, но почему-то не сказал.

Не всем нужно решать всё это автоматически.

Не всем нужен mock.

Не всем нужно решать всё это автоматически.

Да, это одна из причин непустоты множеств юзеров винды, макоси и слаквы.

Не всем нужен mock.

Да, не все собирают пакеты.

rpmbuild вполне собирает пакеты.

rpmbuild вполне собирает пакеты.

Скорее ругается на отсутствие сборочных зависимостей.

Как будто проблема в случае чего доустановить сборочные зависимости руками.

Как будто проблема в случае чего доустановить сборочные зависимости руками.

Все, что можно автоматизировать, следует автоматизировать — основы системного администрирования. Это раз. Во-вторых, перед тем, как комментить здесь, я собрал твой .src.rpm для разных версий Магейи, не слезая со своей Федоры. В chroot-контейнерах mock. Как бы я это сделал без него?

mock, конечно, даёт дополнительные возможности, но и жруч. Он каждый раз в chroot'е разворачивает гигабайты нужной системы заново, да ещё и начинает хранить все эти пакеты в кэше.

В Slackware юзеры спокойно живут без всего этого и возможности собирать пакеты под другие версии систем.

Как бы я это сделал без него?

В слакве это не нужно.

Кто бы сомневался.

mock <…> в chroot'е разворачивает гигабайты

└► su -c "du -chsx /var/lib/mock/mageia-*"; df -h /var/lib/mock/
518M	/var/lib/mock/mageia-6-x86_64
650M	/var/lib/mock/mageia-cauldron-x86_64
1,2G	total
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/homepc-lv_root   80G   70G  6,2G  92% /

О да, ги-га-бай-ты! Впрочем, уж тебя-то это смущать не должно.

и начинает хранить все эти пакеты в кэше

Ты предпочел бы каждый раз качать заново?

mock хранит пакеты и работает с ними в корневом разделе (если не выносить ту же директорию /var на ещё отдельный раздел), а большой корневой раздел юзеру ни разу не нужен (не говоря уже о том, что сейчас полно неттопов и ноутбуков, где стоят SSD по 29 гигов (из них юзер может занять системой 14-17 гигов (без mock'a))). Соответственно, свои пользовательские терабайты файлов юзеру удобнее хранить на других разделах (и других носителях). При том, что корневой раздел загаживать ни разу не желательно.

Ты предпочел бы каждый раз качать заново?

Я предпочитаю пользоваться локальными зеркалами репозиториев на внешних жёстких дисках.

mock хранит пакеты и работает с ними в корневом разделе

Раскомментируй и исправь по вкусу строки

# config_opts['basedir'] = '/var/lib/mock/'
# config_opts['cache_topdir'] = '/var/cache/mock'

О. Спасибо. Это другое дело.