Решено в два раза сократить время поддержки не LTS-релизов Ubuntu и открыть постоянно обновляемый репозиторий

Нужно делать по аналогии с rubygems, когда библиотеки нескольких версий спокойно сосуществуют. Тогда будет выбираться и кешироваться определенный набор неконфликтующих либ (Gemfile.lock), и где-то должны быть указаны предпочтения (Gemfile). Тогда фиксация станет более плавной. Минус - наличие в системе неподдерживаемых либ, но для их удаления можно сделать специальную операцию в установщике. Хочу такую систему!

реализуемо в любом дистре без его модификации.

В генте у многих пакетов есть USE static. Тем не менее не забывай про упоротые билд-системы, у которых с этим могут быть проблемы. Вариант - выкинуть билд-систему и собрать пакет из 100500 файлов-исходников руками - не предлагать.

вот если ты захочешь поставить няшку, ты её что, патчить будешь? ПМ не даст поставить няшку из- за тухлости либы или вообще из-за дыр, и юзер поставит по твоей методе. Как это он всегда делал, делает, и будет делать.

Ну и о чём спор? Я всего лишь предлагаю облегчить это дело, например запилить отдельный реп для приложений, собранных таким образом. Впрочем, идея не нова и уже реализовано не раз, просто в массы не пошло из-за религии. А дыры, так никто не мешает мейнтейнерам этой репы пересобирать пакеты с исправленными библиотеками.

кавычки лишние.

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

на сервере я долго стоял в очереди и долго ждал пересборки.

Пробовали

osc help build

Нужно делать по аналогии с rubygems, когда библиотеки нескольких версий спокойно сосуществуют. Тогда будет выбираться и кешироваться определенный набор неконфликтующих либ (Gemfile.lock), и где-то должны быть указаны предпочтения (Gemfile). Тогда фиксация станет более плавной. Минус - наличие в системе неподдерживаемых либ, но для их удаления можно сделать специальную операцию в установщике. Хочу такую систему!

+++

Хочу такую систему!

Так сделай.

Ну и о чём спор? Я всего лишь предлагаю облегчить это дело, например запилить отдельный реп для приложений, собранных таким образом. Впрочем, идея не нова и уже реализовано не раз, просто в массы не пошло из-за религии. А дыры, так никто не мешает мейнтейнерам этой репы пересобирать пакеты с исправленными библиотеками.

какой ты всё же упёртый ☹

Проблема не в религии, а в том, что данный подход ведёт к помойке. Попробуй покушать в помойке - это во первых долго, во вторых сложно, а в третьих даже опасно.

Ну, это уже не стандартный dist-upgrade. А последний раз так же делал. А ты в следующий раз попробуй обновиться стандартными средствами. ;-)

Мне в этом плане нравится подход Дебьянщиков, указывать в репах симплинки для веток. Прописал в репах stable и забыл. Только важные конфиги бэкапить.

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

проблемы с пробелами возникают не из-за кавычек, а из-за того, что не понимают, зачем их ставить. И не ставят. Или наоборот - ставят везде где надо, и где не надо. И то и другое приводит к проблемам. Например твой код сломается, если заменить \; на «+». А это было-бы неплохо сделать, для того, что-бы твой код так не тормозил из-за 100500 fork'ов. Как раз тот случай, когда быдлокодер сам тормозит работу кода, а потом обвиняет ЯП в кривости. А проблема - в кавычках. Sed работает по разному если ей передать 100500 имён файлов, и если строку с именами 100500 файлов.

Сам подложил грабли, на которые ты обязательно наступишь.

поясни? Я не очень в курсе, как оно собирается «на сервере OpenSuSe»?

Пишешь spec-файл и собирается rpm пакет. Логично что приоритет сборки пакетов Васи Пупкина минимален и он будет стоять в очереди, особенно если пересобирают что-то крупное.

Проблема не в религии, а в том, что данный подход ведёт к помойке. Попробуй покушать в помойке - это во первых долго, во вторых сложно, а в третьих даже опасно.

Никто к этому никого не принуждает. Если пользователю это нужно, пусть разводит помойку, я же не говорю делать это по умолчанию, как раз наоборот. В любом случае рано или поздно Canonical придется как-то решать описанную мной проблему.

Пишешь spec-файл и собирается rpm пакет. Логично что приоритет сборки пакетов Васи Пупкина минимален и он будет стоять в очереди, особенно если пересобирают что-то крупное.

Вася может собрать пакет локально, и я не понимаю, почему этот пакетне соберётся на сервере? А что до времени, то оно волнует только какого-то Петю, который может скачать пакет прямо от Васи. Ну а если «петь» много, пусть приоритет Васи повышают.

строку с именами 100500 файлов.

Длина команды ограничена, bash просто выдаст ошибку и не выполнит её.

Никто к этому никого не принуждает. Если пользователю это нужно, пусть разводит помойку, я же не говорю делать это по умолчанию, как раз наоборот. В любом случае рано или поздно Canonical придется как-то решать описанную мной проблему.

у этой проблемы есть _только_ два решения:

• winway - разрешить юзеру
• linux way - не разрешать юзеру

Вася может собрать пакет локально

Может одной командой.

я не понимаю, почему этот пакетне соберётся на сервере?

Удобнее если собирать тянущие друг друга по зависимостям пакеты. Или когда сборка требует очень много ресурсов. Хотя большинство делает это просто по привычке.

Ну а если «петь» много, пусть приоритет Васи повышают.

Нет, для сборки в home:* никто ничего не повышает. Есть же тематические репозитории.

Длина команды ограничена, bash просто выдаст ошибку и не выполнит её.

с твоими кавычками в Slackware 10 - так и будет(почти. IRL часть строки проигнориться). Без кавычек - всё сработает. В новой системе с кавычками пожрётся 100500 памяти, и если хватит, то кавычки сработают. Если нет - OOM что-нить убьёт.

Без кавычек в любой системе всё будет работать верно, ибо + режет имена, и кормит команду понемногу, но с кавычками это не работает, ибо параметр один.

Удобнее если собирать тянущие друг друга по зависимостям пакеты. Или когда сборка требует очень много ресурсов. Хотя большинство делает это просто по привычке.

значит Вася - ССЗБ.

linux way - не разрешать юзеру

И эти люди нам втирают что-то про свободу.

но с кавычками это не работает, ибо параметр один.

Ну в таком случае наверное можно использовать \«{}\», или как ещё обработать файлы с пробелами в именах?

linux way - не разрешать юзеру

И эти люди втирают нам втирают что-то про свободу.

задумайся, нужны-ли в свободном обществе заборчики на крыше, которые ограничивают свободу Свободных юзеров с этой крыши свободно упасть?

Очевидно - да (даже в Ветхом Завете так написано), ибо очевидно, что большинство юзеров с криши падать не хотят, но будут таки случайно падать. А кто захочет упасть специально - через забор можно и перелезть.

значит Вася - ССЗБ.

quiet_readonly наверно первый жалующийся на такое положение дел за долгое время.

Ну в таком случае наверное можно использовать \«{}\»

нельзя. Тогда кавычки войдут в имя.

или как ещё обработать файлы с пробелами в именах?

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

И эти люди нам втирают что-то про свободу.

За свободой к Столлману, а тут opensource.

А кто захочет упасть специально - через забор можно и перелезть.

То есть воспользоваться этим репозиторием.

За свободой к Столлману

у него одни запреты.

То есть воспользоваться этим репозиторием.

это ты делал диалог в венде «файлы из интернета могут нанести вашему компьютеру...»? Тогда у меня для тебя плохие новости - юзеры игнорят твой диалог, и даже его ни разу не прочитали. Смирись.

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

В данном случае они были необязательны, потому что пробелов нет в именах. А как поступить, если я хочу обработать каталог с файлами, имеющими пробелы в именах? {} \; вызывает ошибку в таком случае, т.к. хватает только часть имени файла до пробела.

А как поступить, если я хочу обработать каталог с файлами, имеющими пробелы в именах? {} \; вызывает ошибку в таком случае, т.к. хватает только часть имени файла до пробела.

ты вправду такой, или прикидываешься?

$ find -exec file {} \;
.: directory
./2 2: empty
./3 3: empty
./1 1: empty

Но решать что-то надо. Сторонним разработчикам не хочется постоянно отслеживать изменения в используемых библиотеках и каждые полгода переписывать продукт, чтобы он продолжал работать в актуальной версии дистра. Им нужно один раз выпустить чтобы оно и через десять лет работало. А так как стандарта для этого нет, то каждый поступает по своему, в итоге система ещё больше засирается. Некоторые срут в $PATH, например.
А так была бы в системе для них изолированная помойка, которую при желании можно всю выпилить одной командой.

ты вправду такой, или прикидываешься?

Таки да, работает. Просто когда-то давно без кавычек в find у меня возникла ошибка, я с тех пор ими и пользуюсь.

Но решать что-то надо. <...> Некоторые срут в $PATH, например.

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

тут две проблемы: во первых, ты своим способом только спровоцируешь разрабов к засиранию, и засирать они именно систему будут, т.е. срать в системный $PATH. А во вторых - стандарты и правила есть, просто не все могут и хотят их придерживаться. Точнее все не могут и не хотят. А - надо. Для того и нужны маинтейнеры, дабы приводить весь софт к единому знаменателю - стандарту данного дистрибутива.

Таки да, работает. Просто когда-то давно без кавычек в find у меня возникла ошибка, я с тех пор ими и пользуюсь.

это не ошибка - система просто среагировала не так, как тебе хотелось. А с пробелами - так как ты хотел. Я уж не знаю, в чём была проблема тогда, но вот в данном конкретном случае, с командой sed -i можно огрести проблем именно с кавычками, а не без них.

Лучше отключи синдром утёнка, и включи мозг. Метод тыка == мина замедленного действия, ты тогда натыкал неправильное решение, которое работало, но в проблеме так и не разобрался.

только спровоцируешь разрабов к засиранию, и засирать они именно систему будут, т.е. срать в системный $PATH.

Не обязательно. Достаточно туда прописать один лишь /opt/bin, где будут находиться симлинки на всякие /opt/program-name/version/bin/program.

Не обязательно. Достаточно туда прописать один лишь /opt/bin, где будут находиться симлинки на всякие /opt/program-name/version/bin/program.

ну да, и все сразу ВНЕЗАПНО тебя стали слушать. Ты король что-ли?

ну да, и все сразу ВНЕЗАПНО тебя стали слушать. Ты король что-ли?

Меня нет, а вот Марка может быть.

эти программы тут вообще не при чем

а кто тогда за это отвечает?

Меня нет, а вот Марка может быть.

программы от Марка ставятся в /usr/bin/, а оно и так в PATH. А помойка ставится куда хочет, скажи спасибо, если в /opt.

Потому что нормально обновляться убунта не умеет.

Мне делает смешно, что это «говорит опенсуся», которую реально надо ставить с нуля при новом релизе))

Мне делает смешно, что это «говорит опенсуся», которую реально надо ставить с нуля при новом релизе))

Там давно уже все хорошо с этим делом.

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

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

И что? Так и надо, ради этого всё и затевалось. А все остальные программы, установленные обычным образом, будут продолжать использовать библиотеки из /usr/lib как обычно.

Речь о дефолтных репах шла

никто не предлагал совать вендовый стиль в дефолтные репы.

ты бы это, определился бы штоль :D

Не вырывай из контекста, давай ссылку на комментарий, где я предлагал совать windows way в дефолтные репы, а то я дам ссылку на твой тупняк в логах чата :D

Я бы вообще отказался от не-LTS, нафиг говно глючное.

Интересно, будет ли поддерживаться обновление LTS N -> LTS N+1, минуя промежуточные не-LTS релизы.

https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#Upgrading_...

Там написано «Follow the on-screen instructions» - вдруг они предлагают последовательное обновление до всех промежуточных релизов.

Интересно, будет ли поддерживаться обновление LTS N -> LTS N+1, минуя промежуточные не-LTS релизы.

А если просто в sources.list заменить название релиза на следующий lts и обновиться с помощью dist-upgrade, неужели не получится?

Я точно знаю, что на Debian нельзя обновляться через релиз (Lenny -> Wheezy - это фейл). Вот и интересно - в Убунте что-то сделают, или как обычно - просто возьмут то, что в Debian?