Fedora 18 будет включать MATE и Cinnamon

популярность зато является синонимом большого количества тестеров,и, как следствие, большей вероятностью отловить баги (и, ессесна, пофиксить)

Вот в сааамом последнем ошибочка. За примерами софта самой популярной ОС далеко ходить не надо.

можно

как, например?

популярность зато является синонимом большого количества тестеров,и, как следствие, большей вероятностью отловить баги (и, ессесна, пофиксить)

Тестеров в убунте много, только баги фиксить нам некому...

Вот в сааамом последнем ошибочка.

ессесно оно не гарантируется на 100%, но вероятность что обнаруженный баг будет пофиксен, всё-таки больше, чем вероятность фикса необнаруженного

как, например?

пакетнейм1 | пакетнейм2 в depends-ах

только баги фиксить нам некому...

вам?

пакетнейм1 | пакетнейм2 в depends-ах

И версии тоже также, вручную, да? Ну-ну.

качество бубунты за последние 5 лет выросло,

4.2

именно

и много ты видел хомячков, которые ошиваются на багтрекерах, а не в соцсетях?

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

зависимость от файлов - гораздо более ущербная практика

чем?

Чем ущербная? Тем что в dpkg не поддерживается?

4.2

4.2, говорю тебе как человек пользовавшийся (к счастью эпизодически) в лохматом 2007м году бубунтой, у которой на ровном месте падал gaim, периодически нужно было перезапускать детект звуковушки, так как система её теряла, ну и куча других ништяков.

Прожорливость выросла, да, но это проблема не только и не столько бубунты.

да, но это проблема не только и не столько бубунты.

особенно unity, ага.

как человек пользовавшийся (к счастью эпизодически) в лохматом 2007м году бубунтой

как человек имел дело (к счастью эпизодически) c 2006 по 2012 год, так что пиарить иди к людям, которые никогда ее не видели и смогут стать халявными тестерами.

да на тебя ваще всем насрать

пральна. откуда поделия каноникла возьмутся в венде?

Патчи на Systemd от мейнтейнеров Арча там тоже вряд ли примут

Федора может и не примет, но Поттеринг уже принимал их не раз.

пральна. откуда поделия каноникла возьмутся в венде?

openSUSE 12.2. Что из поделий каноникала тут используется?

Поттеринг уже принимал их не раз.

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

Раз не нужны - не аргумент.

Лично мне не нужны, а там уже дело вкуса каждого

Коньки не нужны

Не нужны, все-равно 99% рабочего времени рабочий стол не виден. У меня даже обоев нет.

И часто может игнорироваться по причине ограниченности команды разработчиков, ресурсов которой во-первых на все заведомо не хватит, во-вторых сначала будут чинить более приоритетные баги, вероятность детекта которых достаточно велика и без толпы third-party тестеров, и в-третьих которая сделает несколько самых горящих фиксов, а потом уйдет следующую версию пилить, чтобы завтра з/п тоже заплатили.

тут товарищи интересуются, что он такого принимал

Патчи.

Однооконный одновременной является однодокументным

ЧТОА?

у сиськи даже тестеров нет, чоужтам))

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

кастую debian

Это и в dpkg не обязательно - руками можно прописать что угодно.

В RPM никто либы руками не прописывает.

Такая возможность есть - значит, ей кто-то пользуется.

Расскажи как сделать по другому?

Если втупую, то создать отображение имя пакета -> набор ELF ABI version, сканировать soшки из пакета и проставлять в зависимость самую старую версию пакета, поддерживающую использованные ABI.

Откуда брать эту старую версию? Что делать, если пакет переименовывался?

Такая возможность есть - значит, ей кто-то пользуется.

Еще раз повторю. ЛИБЫ руками не прописывают. Прописывают разные утилиты командной строки, пакеты с данными и т.д. Например, пакету stuntrally нужно stuntrally-data.

Из символов в слинкованном бинарнике это не очевидно, поэтому такую зависимость пропишут вручную.

сканировать soшки из пакета и проставлять в зависимость самую старую версию пакета, поддерживающую использованные ABI.

А если ABI будет меняться в будущем? Откуда ты узнаешь первую версию, с которой нужное тебе ABI поддерживаться уже НЕ БУДЕТ? С помощью машины времени?

В дебобунте для этого придуман специальный костыль — вкорячивание версии в имя пакета :)

А в smplayer пропишут вручную зависимость от /usr/bin/mplayer.

Заметь, что не от пакета Mplayer, а от исполняемого файла. Потому что этот файл предоставляют и Mplayer и Mplayer2.

с самой приятной оболочкой по умолчанию

Правда «залипает» переключалка раскладок и иногда мышь «застревает» в vmware, но если заменить юнити... например на опенбокс с лхпанелью - получается вполне вменяемый дистрибутив :)

Откуда брать эту старую версию?

Накапливать. Начальное наполнение - все старые версии есть на archive.debian.org

Что делать, если пакет переименовывался?

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

В дебобунте для этого придуман специальный костыль — вкорячивание версии в имя пакета :)

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

К примеру, если из glibc выкинут устаревший символ libc.so.6(GLIBC_2.2.5)(64bit) то большинство сусевых пакетов будет нормально работать и с новой версией, и только очень старые программы будут ругаться, что им этого символа не хватает.

А в Дебиане по ихним правилам, они обязаны будут переименовать пакет libc, и с новой версией уже не будут работать абсолютно ВСЕ программы, упакованные до этого (будут ругаться на зависимости). Причем, судя по текущему имени этого пакета в Дебиане, libc6, они его уже переименовывали уже 6 раз.

Такая возможность есть - значит, ей кто-то пользуется.

Еще раз повторю. ЛИБЫ руками не прописывают

Ты уже много чего сказал, не могу же я всему верить.

А если ABI будет меняться в будущем?

То что?

Откуда ты узнаешь первую версию, с которой нужное тебе ABI поддерживаться уже НЕ БУДЕТ?

Поддерживаемый ABI записан в ELF. Для тех, кто медленно думает: предлагается примерно то же, что делает генератор зависимостей RPM.

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

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

Накапливать. Начальное наполнение - все старые версии есть на archive.debian.org

То есть на билд-машине надо подключать все имеющиеся репозитории? Это идиотизм. Кстати, apt только относительно недавно научился работать с сотнями тысяч пакетов, до этого ему крышу сносило :)

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

Какой именно?

Костыли это всё и увеличение сложности, почему не сделать как сделано у людей в стандартном (lsb) пакетном менеджере rpm ?

Поддерживаемый ABI записан в ELF. Для тех, кто медленно думает: предлагается примерно то же, что делает генератор зависимостей RPM.

То есть, зависимости по файлам/версии ABI?

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

К примеру, если из glibc выкинут устаревший символ libc.so.6(GLIBC_2.2.5)(64bit) то большинство сусевых пакетов будет нормально работать и с новой версией, и только очень старые программы будут ругаться, что им этого символа не хватает.

Ну ахренеть. Из зависимостей Firefox 17:

libc.so.6(GLIBC_2.2.5)(64bit)  

Такая вот устаревшая программа.

К примеру, если из glibc выкинут устаревший символ libc.so.6(GLIBC_2.2.5)(64bit) то большинство сусевых пакетов будет нормально работать и с новой версией, и только очень старые программы будут ругаться, что им этого символа не хватает.

Уважаемый!

1. Из glibc не выкинут ничего (без смены soname)

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

P. S. И, блин, ты сам-то поинмаешь, что пишешь? «символ libc.so.6(GLIBC_2.2.5)(64bit) » - это что вообще такое?

Слейся.

С чем сравнивали?

С дистрибутивом, в котором не работают usb-модемы из коробки (да, это намек на opensuse)

То есть, зависимости по файлам/версии ABI?

Нет.

скрипт НИКАК не может предсказать, какая версия будет первой неподходящей.

Он ищет самую младшую подходящую.

Такая вот устаревшая программа.

Ну это же просто пример, речь идет о любой либе, не только glibc.

Кстати, для устаревших программ в openSUSE идет пакет glibc-obsolete, в который попадают устаревшие либы. А в Дебиане в случае исключения какой-то либы или символа из libc должны будут переименовать этот пакет и сразу сломают зависимости всех старых программ.

И запишет туда libwtf (>= 1.0.1), а в libwtf (>= 1.1.0) сломается ABI и всё перестанет работать.

То есть на билд-машине надо подключать все имеющиеся репозитории?

Нет.

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

Какой именно?

«Любой из» - это «любой из тех, что отвечают критерию». В зависимость входят все, зависимость является удовлетворенной при наличии любого.

Костыли это всё и увеличение сложности, почему не сделать как сделано у людей в стандартном (lsb) пакетном менеджере rpm ?

Не чини то, что не сломалось.

К примеру, если из glibc выкинут устаревший символ libc.so.6(GLIBC_2.2.5)(64bit) то большинство сусевых пакетов будет нормально работать и с новой версией

феерическая чушь

1. Из glibc не выкинут ничего (без смены soname)

Да, soname поменяют, дальше что? В suse могут сделать симлинк на старый soname и жить дальше. В Дебине должны будут поменять имя пакета.

К тому же, в glibc не одна только либа, а несколько. Некоторые из них мало используются и могут быть выкинуты в будущих версиях. Опять Дебиан должет будет переименовывать пакет. А в suse эти либы просто попадут в отдельный пакет glibc-obsolete и те программы, которым они нужны, будут этот пакет устанавливать по зависимостях, в дополнение к новому glibc.

Уважаемый, а поведайте историю libc.so.6. Не троллинга ради, а интересу для. Ну или пните, где почитать можно

Нет.

Тогда где брать версию пакета?

Не чини то, что не сломалось.

Оно не сломалось, оно просто не работает