Debian анонсировал цели будущего релиза

Ждем 2 года.

Обещанного три года ждутЪ.

Что такое "двойная компиляция"(Double compilation support)?

>Поддержка kFreeBSD, первой не-Linux архитектуры в Debian.

эх, ещё б опенсолярку..

Сие осталось для меня непознанным. В анонсе ничего не сказано подробного. На просторах гугла нашел это:
http://forums.debian.net/viewtopic.php?f=19&t=28468
Мне ссылка мало чего сказала, надеюсь, вам понятнее будет.

>поддержка "двойной компиляции" (Double compilation support).

это о чем они? кто-нибудь в курсе подробностей?

может в 2 прохода? Сначала оптимизирует, а потом компилирует.

Ага, получил сегодня утром письмо из их рассылки.
А что насчёт этого:

> Подготовка к новому формату пакетов.

Они тоже на .xz переходить собрались, что ли?

А по ссылке слабо сходить?

предложи Мёрдоку, может по старой дружбе и ядро опенсолярки выпилит

>Что такое "двойная компиляция"(Double compilation support)?

Двойная компиляция значит, что dpkg-buildpackage, вызванный для построения пакета, должен отработать правильно два раза. Другими словами, первая "компиляция" оставляет за собой правильное дерево файлов, пригодное для повторной компиляции.

Дебиян молодец, пусть трудятся - ведь именно их детьми Линукс сейчас попсеет.

>Поддержка многоплатформенности, в частности, включающая улучшение установки 32-битных пакетов на 64-битную систему.

При условии заморозки в декабре хрен успеем.

Всё остальное можно и успеть. Но лучше б мы в декабре не замораживались.

PGO ? было бы вкусно конечно иметь дистрибутив собраный с PGO

но это уж черезчур

http://www.linux.org.ru/jump-message.jsp?msgid=3921347&cid=3921741
вариант JackYF скорее уж

> Подготовка к новому формату пакетов.

Этот "новый формат" несет что-нибудь, кроме новых способов компрессии? Может, это наконец dpkg 2.0?

> Поддержка kFreeBSD, первой не-Linux архитектуры в Debian.
Что за зверь? И надо ли оно?

Ядро FreeBSD, юзерспейс GNUто-дебиановский. Пока что очень сырое.

> Подготовка к новому формату пакетов.

Не понел? deb выпилят? И в пользу чего? rpm, сам с собой несовместимый?

>Поддержка больших файлов (Large File Support).

Однозначно, круто.

>Поддержка kFreeBSD, первой не-Linux архитектуры в Debian.

В топку бсд, где там Hurd?

дебиан и бсд друзья-братья на век! :-)

>Ядро FreeBSD, юзерспейс GNUто-дебиановский. Пока что очень сырое.

А зачем это нужно?

> PGO ? было бы вкусно конечно иметь дистрибутив собраный с PGO

На чем тренировать-то? Для 90% пакетов без бутылки не придумаешь.

>А зачем это нужно?

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

вот поэтому и черезчур ) на весь дистрибутив PGO )

>Поддержка больших файлов (Large File Support).
>Однозначно, круто.

на самом деле не смешно, мне попадался то ли в убунте, то ли в дебиане, кажется все же в дебиане dd (!) собраный без поддержки large files

т.е. он пропускал через себя 4 Гб и падал... впрочем быстро исправили

> А зачем это нужно?

Бытует мнение, что бздяшное ядро в некоторых аспектах лучше линуксячьего. Если M$ имеет профит с бздяхи, то почему бы этот профит не поиметь и debian сообществу?

Хорошие цели. :) Ждем нового выпуска.

>Что такое "двойная компиляция"(Double compilation support)?

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

Прогнал на убунте 10 гигов через dd. На всякий случай удостоверился, что не юзаю fat32. Перекрестился.

Интересно, они осилят дельты?

>Интересно, они осилят дельты?

man debdelta?

>Не понел? deb выпилят? И в пользу чего? rpm, сам с собой несовместимый?

Тролль детектед.

Релиз эволюционного плана, ну тем и лучше, может успеют.

> улучшение установки 32-битных пакетов на 64-битную систему.
> Дальнейшее улучшение процесса QA (Quality Assurance),
> Удаление устарелых библиотек для улучшения безопасности.
> Полная поддержка IPv6.
> Поддержка больших файлов (Large File Support).
> Автоматическое создание debug-пакетов для всего архива.

тихо улыбаясь пользователи *SUSE/SLE* желают проекту всего наилучшего... (особенно с QA...)

RPM - отличная штука. Сам прописывает зависимости. Куча удобных макросов, так что не нужно запоминать длинные цепочки команд. В OpenSUSE/SLE пакеты собираются в chroot, так что нет никаких посторонних файлов, которые не контролируются RPM. Rpmlint вообще отличен - даже проверяет орфографию в описании пакета.
А теперь посмотрим на deb. Вместо одного .spec файла нужно делать несколько файлов, а несколькими файлами неудобно обмениваться. Один файл можно просто скопипастить в pastebin, а с несколькими уже труднее. Чего стоит хотя бы тот же формат патчей в дебе? RPM использует стандартный diff -u формат, а в дебе свои велосипеды, и никакого удобного конвертера - приходится выполнять по десять команд для конвертирования. Так что если бы деб перешел на RPM, а вместе с ней и убунта, и оба бы следовали LSB - куча проблем бы ушла. Но не хотят, так что ССЗБ.

>В топку бсд, где там Hurd?

Уже в топке и не собирается оттуда выходить

А rpm-based дистрах уже появился аналог apt-get autoremove ?

s/А/А\ в/

Может для разработчика RPM и лучше, но как пользователь я с deb уже никуда не уйду. По меньшей мере, если выбирать из бинарных пакетов.

> RPM - отличная штука. [...]

Ну дык иди развивай свой любимый RPM-дистр, чего ты в этот тред припёрся? Заодно расскажи, почему в RPM-дистрибутивах tailor зависит сразу от десяти систем контроля версий, почему я не могу установить его только лишь с двумя. Почему у вас огрызок changelog'a на задворках spec'a, почему аналога debian/copyright у RPM'a нет вообще, расскажи об ИИ, который прописывает зависимости. О pbuilder/sbuild адепт суси, что характерно, не слышал, lintian туда же. Пакеты, между которыми конфликты даже не думают прописывать... Так что идите дальше пилите свой OBS, который никак debhelper>4 не осилит :)


Что-то сегодня сусятники активизировались сильно. К чему бы это?

>Поддержка многоплатформенности, в частности, включающая улучшение установки 32-битных пакетов на 64-битную систему.

Кто их просил %)

> тихо улыбаясь пользователи *SUSE/SLE* желают проекту всего наилучшего... (особенно с QA...)

Будучи пользователем _и_ съюза (на работе) _и_ дебиана (дома), могу сказать, что дебиановский qa радует больше ;) Впрочем, в этой плоскости обоим дистрибутивам есть куда развиваться.

В конце концов, компиляторные оптимизации - это довольно экстенсивный путь наращивания производительности. Оптимизация (там, где она вообще нужна) в первую очередь должна проводиться авторами программ на уровне алгоритмов. Как раз то, что мы наблюдаем с dash.

>А rpm-based дистрах уже появился аналог apt-get autoremove ?

Да.

> RPM использует стандартный diff -u формат, а в дебе свои велосипеды, и никакого удобного конвертера - приходится выполнять по десять команд для конвертирования.

Много раз перечитал , вывод: подобное мог написать только пользователь ущербного дистра и неасиливший построение и структуру deb пакетов.
А еще ,расскажи там про идентичность rpm SUSE, Fedora, Mandriva - сами помойку там развели себе....

А где об этом можно почитать? А то похоже у меня криокамера сломалась...

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

а вот кстати не мешала бы оптимизация хотя бы флажками -Os / -O2
потому что ряду пакетов производительный код не нужен , а вот компактность достаточно важна была бы

> Кто их просил %)
А вообще же , изначально это пытались делать для Amd64.