appimage

Это же не пакеты. Appimage создаёт просто запускаемый файл. Никакого версионирования и прочих плюшек там нет.

Какой софт-то хоть? От этого зависят возможные пути развития событий.

Но с универсальными пакетами типа снап и флатпак на центосах туго, блин. По тому, как разработчики их относятся к lts дистрам, делаю вывод, что эти «универсальные пакеты» игрушка, долго не проживет.

Одно из решений будет делать rpm со статически собранными приложениями, устанавливающимимся в /opt, например.

http://nixos.org/nix/

Пакеты со статистической типизацией?

Помоги, плиз. Я пытаюсь поставить nix. Но отсюда https://hydra.nixos.org/job/nix/master/release не могу скачать ни rpm, ни deb, ничего другое - пишет 404 file disappeared. Это временные трудности, или я делаю что-то не так?

даже если это просто свежий gcc

Есть же devtoolset в SCL https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/.

траходром гигантских масштабов

Программисты открывают для себя волшебный мир деплоя. Наймите релиз-инженера, который в курсе федоровской инфраструктуры (koji, spacewalk и проч.)

Программисты открывают для себя волшебный мир деплоя. Наймите релиз-инженера

Ты так говоришь, как будто держишься за такое положение вещей как релиз-инженер :)

Покрутившись в этой ситуации с разных сторон, я все больше прихожу к выводу, что вещи типа SCL, имеют узкое системное применение. И к развертыванию пользовательских приложений имеют опосредованнное отношение.

Система должна быть построена на пакетах, как сейчас и есть, иметь в репах определенное количество полезных приложений. Опять же, как и сейчас есть. Для компиляторов, либ подходит SCL.

А вот для приложений вида CAD, граф.редакторов, всяких Calibre, Kodi, а так же IDEA, Eclipse(и сред на них основанных), проприетарных коммерческих приложений типа скайпа и MagicDraw - нужны менеджеры типа nix или flatpak. И желательно, что бы «остался только один», что бы разраб давай на сайте (том же гитхабе) ссылки на exe, dmg, .flatpak и src.tar.gz. Не смущая пользователей openSuse кривыми rpm, которые вероятнее всего не подойдут, потому что собраны под altlinux.

Ты так говоришь, как будто держишься за такое положение вещей как релиз-инженер :)

А то! Вдруг бобла предложат >(^__^)< Но вообще написано: дохренища серверов на Centos 6 и 7. Какие нафиг CAD, скайпы и т.п.

дохренища серверов на Centos 6 и 7. Какие нафиг CAD, скайпы и т.п.

Я так, для общности. Сюда, конечно, надо отнести любое интересующее кастомера ПО, которое проблемно сейчас развернуть на каком то дистре (не только цент).

Вообще я жду от ТС примеры по, из-за чего он этот топик затеял, интересно

Какой софт-то хоть? От этого зависят возможные пути развития событий.

Системный софт, серверы, etc.

Одно из решений будет делать rpm со статически собранными приложениями, устанавливающимимся в /opt, например.

GPL. Можно сделать примерно то же, только с обвязкой вокруг dlopen, но это уже в сторону треша.

Алсо glibc не умеет в статическую линковку никак вообще.

Есть же devtoolset в SCL https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/.

Есть, но там тоже говно мамонта (gcc 5.2.1). Я хочу свежее.

Программисты открывают для себя волшебный мир деплоя. Наймите релиз-инженера, который в курсе федоровской инфраструктуры (koji, spacewalk и проч.)

И как федоровская инфраструктура поможет со сборкой новых тулчейнов под центось? Я уже не говорю о том, что между el6 и el7 rpm-спеки не совсем совместимы, и там тоже куча геморроя вылезает.

TL;DR я не хочу строить костыли вокруг rpm, я хочу другой пакетный менеджер без этого геморроя. Потому что пока единственным решением я вижу docker, и меня это не радует.

И как федоровская инфраструктура поможет со сборкой новых тулчейнов под центось?

Энтерпрайз линукс -- младший братик федоры, если что. Всё оттуда берётся.

Есть, но там тоже говно мамонта (gcc 5.2.1). Я хочу свежее.

ты уверен, что тебе это действительно надо? Или это просто «что бы было».

Системный софт, серверы, etc.

оно на какой платформе: java, node.js, или, может, нативные написанные на C приложения?

ты уверен, что тебе это действительно надо? Или это просто «что бы было».

Оно надо, потому что новый С++ имеет довольно много вкусных фишек.

оно на какой платформе: java, node.js, или, может, нативные написанные на C приложения?

Нативный код на C++.

Энтерпрайз линукс — младший братик федоры, если что. Всё оттуда берётся.

Я не тот вопрос задал, наверное. Этот набор страшных слов как-то поможет мне безболезненно собрать один пакет, работающий под el6 и под el7? Если да, можно ли встроить этот набор страшных слов в нашу существующую CI-систему (Teamcity) ? Мне нужно, чтобы оба ответа были положительные, иначе то что ты предлагаешь мне не подходит.

Этот набор страшных слов как-то поможет мне безболезненно собрать один пакет, работающий под el6 и под el7?

Поможет два собрать. Из одного спека.

можно ли встроить этот набор страшных слов в нашу существующую CI-систему (Teamcity)

Да, будете автоматически генерить свои корпоративные репы из базы данных, с них деплоить хоть в TC, хоть в джеркинс.

Поможет два собрать. Из одного спека.

Спасибо, но это как раз то, от чего я хочу избавиться.

Какая к лешему разница сколько файлов, если их одна машина сама генерит, другая сама ставит.

Какая к лешему разница сколько файлов, если их одна машина сама генерит, другая сама ставит.

Разница в необходимости поддерживать актуальные версии зависимостей. Особенно это проблема для el6. Или ты думаешь, спеки для них сами из астрала прилетают?

Или ты думаешь, спеки для них сами из астрала прилетают?

Нет, но зато спеки из астрала будут прилетать под "пакетный менеджер без геморроя"™.

Нет, но зато спеки из астрала будут прилетать под «пакетный менеджер без геморроя»™.

В этом случае у меня будет в два раза меньше работы, потому что достаточно будет собрать зависимости один раз, а не два. Видишь, к чему я веду?

Наймите релиз-инженера, который в курсе федоровской инфраструктуры (koji, spacewalk и проч.)

- А можно мне не дрочить анус ногой во время разработки?
- Нет, давайте лучше наймем какого-нибудь парня и уже он будет дрочить твой анус!

Есть же devtoolset в SCL https://www.softwarecollections.org/en/scls/rhscl/devtoolset-4/.

Есть, но там тоже говно мамонта (gcc 5.2.1). Я хочу свежее.

5.3.1

scl enable devtoolset-4 bash

gcc -v

gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC)

В той же Ubuntu 16.04

gcc version 5.4.1 20160904 (Ubuntu 5.4.1-2ubuntu1~16.04)

Не сильно новее...

Ну ты сравнил одно говно с другим, молодец. Ещё бы дебиан приплёл.

я делаю что-то не так?

Очевидно, ты ставишь ненужно. Сама жизнь даёт тебе знаки, значение которых ты упорно отказываешься понимать.

Итак, подведём итоги

Внезапно оказалось что актуальный devtoolset - 6. Там gcc 6.2.1. Заметил случайно, пока копался с одним багом в gdb, так как он не отображается в поиске на сайте. Ну и судя по числу историй успеха с "универсальными пакетами", которые тебе накидали (то есть ровно ноль), скорее всего его ставить и придётся.

Ну и судя по числу историй успеха с «универсальными пакетами», которые тебе накидали (то есть ровно ноль), скорее всего его ставить и придётся.

Да нет, мы уже собрали наш софт под Alpine и сунули в Docker. Это оказалось куда проще.

Ну тож неплохо :)

Ну тож неплохо :)

Плохо, на самом деле. Docker делает чуть больше, чем нам нужно, и при этом как пакетный менеджер он не то чтобы очень удобен. Поэтому пришлось сделать пару костылей, которые, тем не менее, намного проще и безгемморнее, чем та задница с RPM.