LINUX.ORG.RU

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

 


0

0

В соответствии со своим недавним решением о фиксации времен заморозки релизов, команда Debian подготовила список целей будущего релиза Squeeze.

  • Поддержка многоплатформенности, в частности, включающая улучшение установки 32-битных пакетов на 64-битную систему.
  • Поддержка kFreeBSD, первой не-Linux архитектуры в Debian.
  • Улучшение производительности при загрузке, включая использование dash в качестве нового shell по-умолчанию, и систему загрузки, основанную на зависимостях (dependency-based boot system).
  • Дальнейшее улучшение процесса QA (Quality Assurance), одним из результатов которого должно стать повышение качества пакетов. В частности,
    • «чистая» установка, обновление и удаление всех пакетов,
    • автоматическое непринятие пакетов, не проходящих базовых проверок,
    • поддержка «двойной компиляции» (Double compilation support).
  • Подготовка к новому формату пакетов.
  • Удаление устарелых библиотек для улучшения безопасности.
  • Полная поддержка IPv6.
  • Поддержка больших файлов (Large File Support).
  • Автоматическое создание debug-пакетов для всего архива.

и многое другое.

>>> Подробности



Проверено: Shaman007 ()
Ответ на: комментарий от iZEN
Сие осталось для меня непознанным. В анонсе ничего не сказано подробного. На просторах гугла нашел это:
http://forums.debian.net/viewtopic.php?f=19&t=28468
Мне ссылка мало чего сказала, надеюсь, вам понятнее будет.
ksv
() автор топика
>поддержка "двойной компиляции" (Double compilation support).

это о чем они? кто-нибудь в курсе подробностей?
Sylvia ★★★★★
()
Ага, получил сегодня утром письмо из их рассылки.
А что насчёт этого:

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


Они тоже на .xz переходить собрались, что ли?
Cancellor ★★★★☆
()
Ответ на: комментарий от thevery
предложи Мёрдоку, может по старой дружбе и ядро опенсолярки выпилит
oc
()
Ответ на: комментарий от iZEN
>Что такое "двойная компиляция"(Double compilation support)?

Двойная компиляция значит, что dpkg-buildpackage, вызванный для построения пакета, должен отработать правильно два раза. Другими словами, первая "компиляция" оставляет за собой правильное дерево файлов, пригодное для повторной компиляции.
JackYF ★★★★
()
Дебиян молодец, пусть трудятся - ведь именно их детьми Линукс сейчас попсеет.
Hokum ☆☆☆☆
()
>Поддержка многоплатформенности, в частности, включающая улучшение установки 32-битных пакетов на 64-битную систему.

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

Всё остальное можно и успеть. Но лучше б мы в декабре не замораживались.
JackYF ★★★★
()
> Подготовка к новому формату пакетов.

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

tailgunner ★★★★★
()
> Поддержка kFreeBSD, первой не-Linux архитектуры в Debian.
Что за зверь? И надо ли оно?
pento ★★★★★
()
> Подготовка к новому формату пакетов.

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

mixer82
()
дебиан и бсд друзья-братья на век! :-)
hizel ★★★★★
()
Ответ на: комментарий от Sylvia
> PGO ? было бы вкусно конечно иметь дистрибутив собраный с PGO

На чем тренировать-то? Для 90% пакетов без бутылки не придумаешь.
Manhunt ★★★★★
()
Ответ на: комментарий от NoMad
>А зачем это нужно?

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

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


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

т.е. он пропускал через себя 4 Гб и падал... впрочем быстро исправили
Sylvia ★★★★★
()
Ответ на: комментарий от NoMad
> А зачем это нужно?

Бытует мнение, что бздяшное ядро в некоторых аспектах лучше линуксячьего. Если M$ имеет профит с бздяхи, то почему бы этот профит не поиметь и debian сообществу?
Manhunt ★★★★★
()
Ответ на: комментарий от iZEN
>Что такое "двойная компиляция"(Double compilation support)?

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

WFrag ★★★★
()
Ответ на: комментарий от Sylvia
Прогнал на убунте 10 гигов через dd. На всякий случай удостоверился, что не юзаю fat32. Перекрестился.
melkor217 ★★★★★
()
Ответ на: комментарий от ferhiord
>Интересно, они осилят дельты?

man debdelta?
Pavval ★★★★★
()
Ответ на: комментарий от mixer82
>Не понел? deb выпилят? И в пользу чего? rpm, сам с собой несовместимый?

Тролль детектед.
JackYF ★★★★
()
Релиз эволюционного плана, ну тем и лучше, может успеют.
MuZHiK-2 ★★★★
()
> улучшение установки 32-битных пакетов на 64-битную систему.
> Дальнейшее улучшение процесса QA (Quality Assurance),

> Удаление устарелых библиотек для улучшения безопасности.

> Полная поддержка IPv6.

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

> Автоматическое создание debug-пакетов для всего архива.


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

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

alex-w ★★★★★
()
Ответ на: комментарий от h31
Может для разработчика RPM и лучше, но как пользователь я с deb уже никуда не уйду. По меньшей мере, если выбирать из бинарных пакетов.
CryAngel
()
Ответ на: комментарий от h31
> RPM - отличная штука. [...]

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


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

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

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

Будучи пользователем _и_ съюза (на работе) _и_ дебиана (дома), могу сказать, что дебиановский qa радует больше ;) Впрочем, в этой плоскости обоим дистрибутивам есть куда развиваться.
Manhunt ★★★★★
()
Ответ на: комментарий от Sylvia
В конце концов, компиляторные оптимизации - это довольно экстенсивный путь наращивания производительности. Оптимизация (там, где она вообще нужна) в первую очередь должна проводиться авторами программ на уровне алгоритмов. Как раз то, что мы наблюдаем с dash.
Manhunt ★★★★★
()
Ответ на: комментарий от h31
> RPM использует стандартный diff -u формат, а в дебе свои велосипеды, и никакого удобного конвертера - приходится выполнять по десять команд для конвертирования.

Много раз перечитал , вывод: подобное мог написать только пользователь ущербного дистра и неасиливший построение и структуру deb пакетов.
А еще ,расскажи там про идентичность rpm SUSE, Fedora, Mandriva - сами помойку там развели себе....
elipse ★★★
()
Ответ на: комментарий от Zenom
Не совсем аналог, конечно, т. к. он не отслеживает, что было установлено ручками, а что прилетело автоматом. А для исключения удаления того, что пользователь поставил сам, есть опция для игнорирования зависимостей, которые содержат исполнимые файлы.
Zenom ★★★
()
Ответ на: комментарий от Manhunt
а вот кстати не мешала бы оптимизация хотя бы флажками -Os / -O2
потому что ряду пакетов производительный код не нужен , а вот компактность достаточно важна была бы
Sylvia ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.