> > > Добрый день. Я хотел бы узнать, в чем причина больших задержек в > > > выпуске обновленных пакетов KDE? Я знаю много людей, которые > > > используют debian как рабочую систему, и для них Gnome и KDE очень > > > важны (про гном не могу ни чего сказать, т.к. не использую). К > > > этому же относится и KDevelop. Не могли бы вы как-то ускорить > > > процесс сборки? Пожалуйста. :-) > > > > Please go and learn how Debian organization works :). > > If you are ready to help, please start with reading Debian Policy and > > Maintainer's Guide. > > If not, please be patient :). > > I want to help. But can't make acceptable .deb package.
Ну почему же? Почитайте документацию, возьмите имеющееся за образцы ... :) Кстати мне вообще не очень понятно о чём речь. В sarge - KDE 3.2.3, в sid - 3.3.0 (и частично уже 3.3.1) > > > > И еще один маленький вопросик. В чем причина сборки под i386. Лично > > > я не представляю себе машины с процом 386 и соотв. кол. памяти, на > > > которой запустится скажем KDE 3.3. Нет, наверняка запустится... > > > через часа 1,5 и достаточном объеме подкачки ;-) Нельзя ли собирать > > > хотябы для 586/686? > > > > This was talked about zillion of times. > > Optimizing for 586/686 won't give you any measurable speed gain in 99% > > of software. And the for the rest 1% Debian does provide optimized > > versions. > > I think you are wrong. I made (for test) kde3.2 for athlon. Gain 10%-15% > of speed (approximately). И как же это измерялось? :) Да - надеюсь при тестировании i386 deb-ов пакет libc6-i686 стоял? Поменьше эмоций, побольше фактов (C) :) > In any way i386 - too rare used processor to > compile for. I'm wrong? I do not seen this processor for many years, > so... I think it's good to do i586. Есть работающая инфраструктура для сборки пакетов, используемая для сборки всех пакетов. Не думаю, что кто-либо станет её менять, не имея на то веских оснований. Кстати одно такое основание сравнительно недавно случилось. Было выяснено, что при сборке libstdc++ на i386 из-за недоступности атомарных машинных команд вроде cmpxchg и необходимости их эмуляции через mutex-ы имеет место *реальная* потеря производительности. В результате было принято решение делать сборку для 486, а в дебиановские ядра добавить код, эмулирующий при необходимости недостающие инструкции на "настоящих 386" (которые кстати реально сегодня используются много где). Но название архитектуры в архиве при этом остаётся i386 - оно много где прошито, и вносить в систему нестабильности, меняя его, совершенно незачем. Что же касается сборки не под 486, а под старшие x86, то тема поднималась в debian-devel миллион раз, и конкретных результатов измерений, позволяющих утверждать о каком-то реальном припосте производительности от этого, так и не было. Оптимизация под процессор может быть важна для конкретных пакетов. Но так у нас есть kernel-image-*-686-*, libc6-i686, пакеты openssl содержат несколько so-шек, собранных под разные архитектуры, и т.п. Если же вы имеете в виду 64-битные процессоры AMD, то для них есть 64-битная сборка :).
