Вышел RedHat Skipjack Beta2

Интересно, XFree 4.3 успеют до выхода RH 7.3 выпустить, и станут ли редхатовцы менять 4.2 на новую?
Все-таки работоспособность 7.2 желает лучшего. В частности ppp для Win98 клиентов не годный оказался, или может это у меня руки кривые? Но замена ppp на чуть более свежий из rawhide свела все проблемы к нулю.

Опять старьем начинили. :(
gcc-2.96, python-1.5.3 и т.д. Археология не хуже дебиана...

Я конечно понимаю, стабильность, обкатанность, куча пальцОв. Апдейтить тоже можно при желании... В общем, фи.

Mozhet kto stavil uzhe?

Так потому он и 7.3 а не 8.0. :)

>Всего около 450Mb.

Хех, да там 5-ть дисков, что то около 2,5 Гиг в общей сложности, даже если
отбросить 2-а последних, где видимо находятся сырцы, то даже
инсталяционные 3-и первых диска никак не будут весить 450Mb....

Апдейтов 450Мб :) к Skipjack Beta1 (апдейтица по up2date можно)
gcc-2.96 бо с gcc-3 серьезные проблемы и RH не желает повторять историю gcc-2.96. Спокойно доведут до стабильности и в RH8 выпустят.
А python2 имеется: python2-2.2-13 подойдет? ;)
А Skipjackи у меня на 2х машинах стоят с Beta1.

Тима, да и gcc-3 ручками поставить можно. Только, подозреваю, массу всего перекомпилячить придется. С нестабильным gcc-2.96 они тогда поспешили, а со стабильным gcc-3 тормозят... :(

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

>Только, подозреваю, массу всего перекомпилячить придется. С нестабильным
>gcc-2.96 они тогда поспешили, а со стабильным gcc-3 тормозят... :(
Странно... Вот с их апдейтов брал совсем свежий gcc-3.0.4, что то не вижу
что бы они с ним тормозят, что же касается 8-ки, то они хотят включить туда
gcc-3.1 и glibc-2.3, а перекомпилять ничего не надо, работает все нормально.

2CybOrc: какая путаница-то с питонами? никакой путианицы.

> Странно... Вот с их апдейтов брал совсем свежий gcc-3.0.4, > что то не вижу что бы они с ним тормозят

Ты брал gcc3-3.0.4. Чуток разное. Он ставится рядом с gcc. Время от времени надо переключаться между ними (потому как часть библяотек скомпилячена 2.96, а часть 3.0.4), что задалбывает.

С Питоном другая фигня: на сервере фря (я не админ), на рабочем компе RH. Соответственно, в первом случае /usr/bin/python, а во втором /usr/bin/python2. Ферштейн? К тому же, на фига мне два Питона? Это как на предыдущем Дебиане вышло с перлом (он там апгрейдился со скрежетом).

не, не ферштейн.

если на free нету /usr/bin/python2, то нужно попросить админа сделать симлинк. честно говоря, если там py2, то странно что нет /usr/bin/python2. Хотя настолько детально тонкости компиляции птиона я не изучал, темболее как оно собирается на freebsd.

если не нужно два питона - rpm -e ненужный-python ;)))

у меня, например совсем нет "старого" на паре машин. И есть python-provider, пакет который делает всего две вещи -

1. ln -s /usr/bin/python2 /usr/bin/python

2. "provide: python".

по-хорошему, коенчно нужно бы персобрать все пакеты с python2, но мне лень. Совсем лень. То с чем я работаю и так собрано с python2, а стандартные думаю рано или поздно пересобрет сам RH (предположительно в RH8 py1.5.2 совсем выкинут). Они мне не мешают, и я их учить жизни не буду ;)

мне не шашечки, мне ехать...

проблемы с новыми версиями софта, а особенно софта разработчкика и библиотек будут всегда. И "более красиво" оно не решается. Увы. Все это нужно аккуратно обновлять, тестировать и так длаее и тому подобное. И подход, который использует RH с "хитрой" нумерацией пакетов, я считаю вполне удобным. Т.е. я не знаю метода как сделать еще меньше проблем.

Вот тупо лепить например python-2.2 это бааальшие грабли из-за несовместимости версий питона. Допустим какой-то софт написан для py1.5, и в пакет прописано "requre: /usr/bin/python". Обновляет простой человек python-1.5 в python-2.2 и получает граблями по лбу. Оно нада? Не нада.

А насчет gcc-2.96 я лично даже рад, что его не убирают - проги скомпилированные на 3-м работают немного медленнее.

SadAlex.

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

Они сначала протестят, погоняют, а потом, когда все будет спокойно на сердце, они выложат все это в дистрибутиве! ИМХО, это правильно, зачем пихать все новое, но не протестированное на работоспособность!