# политика удаления пакетов или продолжения их существования

## zvn

Прочитал http://www.gentoo.org/proj/en/qa/treecleaners/policy.xml

 *Quote:*   

> 
> 
> PENDING REMOVAL [date] is a status whiteboard phrase we use to indicate when the package is scheduled for removal. PENDING REMOVAL implies you have sent last rites for the package. Please do not forget to send last rites for a package that you masked.
> 
> 

 

Как назначается эта дата?

 *Quote:*   

> Removal Criteria..... Package has no active maintainer. 

 

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

А что в gentoo делают в этом случае? Я в документации никак не могу найти.

В других дистрибутивах от проблем с переходом от устаревших фундаментальных пакетов к новой конструкции уходят с помощью релизов. Как это делают в gentoo? Не в частностях, как здесь http://www.gentoo.org/proj/en/apache/doc/upgrading.xml, а общий подход. Что-то близкое к http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/release-branches.html. Есть ощущение, что релиз gentoo выпускают тогда, когда наступает некоторое затишье, т.е. одновременное совпадение: мало багов регистрируется по пакетам в стабильной ветке, документация поспела, готов новый livecd и т.п.

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

----------

## zvn

Вот дали ответ: https://forums.gentoo.org/viewtopic-t-691061-highlight-.html 30 дней с момента маскировки при наступлении  removal creteria http://www.gentoo.org/proj/en/qa/treecleaners/policy.xml

 *zvn wrote:*   

> 
> 
>  Есть ощущение, что релиз gentoo выпускают тогда, когда наступает некоторое затишье, т.е. одновременное совпадение: мало багов регистрируется по пакетам в стабильной ветке, документация поспела, готов новый livecd и т.п.
> 
> 

 

Про релизы.

http://www.gentoo.org/proj/en/releng/docs/release_guidelines.xml

Но опять всплывает вопрос. Есть ли понятие "период поддержки релиза"? Как вот здесь, к примеру http://www.redhat.com/security/updates/errata/

----------

## ArtSh

 *Quote:*   

> Но опять всплывает вопрос. Есть ли понятие "период поддержки релиза"?

 

Может быть сперва Вы объясните своими словами что значит в Вашем понимании "период поддержки релиза"?

----------

## zvn

 *ArtSh wrote:*   

> Может быть сперва Вы объясните своими словами что значит в Вашем понимании "период поддержки релиза"?

 

Только я сразу хочу сказать, что все прелести gentoo я осознаю  :Smile: 

Я понимаю, что сравнивать релиз gentoo с релизами других дистрибутивов нельзя.

В обычном понимании (может быть, у меня зауженные представления), в течение объявленного периода поддержки

1. В релизе по возможности сохраняется версия ядра, эту версию патчат. 

2. По возможности сохраняется перечень и версии пакетов, эти версии патчат. 

3. Если пакет поддерживать стало некому, то владелец дистрибутива сам изыскивает возможности для продолжения его существования. Редко бывает, что если некому, то некому.

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

Соответственно этим пунктам

1. В gentoo я могу замаскировать версию ядра, с учётом патчей этой версии.

2. В gentoo пакет и версию тоже можно замаскировать, с учётом патчей.

3. Как правило, если некому, то некому  :Smile: 

Т.е. получается, что обычное понимаение релиза я организую сам, путём маскировок, использования оверлеев в случае исключения пакета из официального дерева, сохранения профиля и т.п.

----------

## fank

Что-то совсем ничего не понятно...

Релиз чего??? Дистрибутива? Или софта?

 *Quote:*   

> Может быть сперва Вы объясните своими словами что значит в Вашем понимании "период поддержки релиза"?

 

----------

## zvn

 *fank wrote:*   

> Что-то совсем ничего не понятно...
> 
> Релиз чего??? Дистрибутива? Или софта?
> 
>  *Quote:*   Может быть сперва Вы объясните своими словами что значит в Вашем понимании "период поддержки релиза"? 

 

дистрибутива

----------

## ArtSh

 *zvn wrote:*   

>  *ArtSh wrote:*   Может быть сперва Вы объясните своими словами что значит в Вашем понимании "период поддержки релиза"? 
> 
> В обычном понимании (может быть, у меня зауженные представления), в течение объявленного периода поддержки
> 
> 1. В релизе по возможности сохраняется версия ядра, эту версию патчат. 
> ...

 

1. практически совдпадает со сроком поддержки разработчиками (срок начала периода сдвинут в большую сторону, потому как сперва стабильное ванильное ядро объявляется как ~arch).

2. аналогично как и 1.

3. Честно говоря не слышал о таком повсеместно. обычно если надо самому разработчику или клиенту. Если заинтересованность у кого-то есть, он вполне может проболжить поддерживать ebuild.

----------

## zvn

 *ArtSh wrote:*   

>  *zvn wrote:*   
> 
> В обычном понимании (может быть, у меня зауженные представления), в течение объявленного периода поддержки
> 
> 1. В релизе по возможности сохраняется версия ядра, эту версию патчат. 
> ...

 

Как крайний вариант можно рассмотреть sles, но не 10  :Smile: 

1. sles 9 (смотрю x86_64):  патчили 2.6.5, далее так и не ушли; sles 8 в основном 2.24.21

2. Спорить не буду, тут оценить картинку сложнее, но достаточно много пакетов, версия которых менялась раз в 2 года, в основном свои патчи, вот toochain gcc-3.3.3, glibc-2.3.3, bind-utils-9.2.3 2 года, потом 9.3.4 на последнем издыхании, и серверные mysql-4.0.18, apache2-2.0.49, apache2-2.0.59, cups-1.1.20, samba почаще, openldap2-2.2.24 php4-4.3.4

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

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

Беда в том, что в глазах админящих бинарные дистрибутивы (вот сижу и слушаю лёгкие повизгивания убунтийцев в связи с переходом на новый релиз  :Smile:  , боба видать) именно эта сменяемость версий и исключаемость из реестра является уязвимостью gentoo. Отпинываться от наездов устал. Уход за долго растущим деревом и выращивание овощей-однолеток - это разные стили.

Хотя смысл в сохранении, как в бинарном дистрибутиве есть - запуск коммерческого ПО, сертификация оборудования и т.п.

----------

## _Sir_

Неправильное понимание сути дистрибутива. 

Gentoo -- метадистрибутив. С чего-то надо начинать -- есть "релизы". Но можно загрузиться и с knoppix и установить Gentoo из сети. Суть в другом. Поддерживаются (в последнее время заметно хуже, из-за роста числа пакетов в портеже) зависимости актуальных пакетов между собой. За каким мне нужно фиксировать версию ядра, если я могу просто иметь ядро, которое мне необходимо? Gentoo -- это дистрибутив, который движется вместе с пользователем/админом (сервер), и все его средства ориентированы на то, чтобы это было именно движение, и по возможности, безконфликтное. Никто не мешает поставить сервак на узкую задачу и забыть о нем на пару лет, ничего там не делая. Это уже выбор пользователя данного дистрибутива. 

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

а) соберется; 

б) будет стабильно работать. 

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

Возможностью самостоятельного выбора и принятия решения, а не переноса ответственности на неких далеких мэйнтенеров, пусть даже и за бабки, -- вот что выгодно отличает Gentoo. Если же вы хотите делегировать ответственность на кого-то, пожалуйста, к вашим услугам большой набор "готовых" решений Red Hat, Sun Microsystems, AIX IBM, Novell, Microsoft наконец.

----------

## fank

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

в случае бинарных дистрибутивов политика dist upgrade (в терминологии Debian) насколько мне известно не сильно распространена

по крайней мере, нужно быть психом, чтобы делать такое на hard production сервере

теперь предлагаю поразмыслить над ситуацией

 *Quote:*   

> Никто не мешает поставить сервак на узкую задачу и забыть о нем на пару лет, ничего там не делая.

 

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

возможен ли "плавный" переход от профиля NNNN.N к NNNN.(N+ :Cool: ?

----------

## zvn

 *fank wrote:*   

> тут, на мой взгляд, есть один довольно важный момент, который упускается из виду
> 
> в случае бинарных дистрибутивов политика dist upgrade (в терминологии Debian) насколько мне известно не сильно распространена
> 
> по крайней мере, нужно быть психом, чтобы делать такое на hard production сервере
> ...

 

Насколько я понимаю, dist-upgrade можно заменить работой человека по анализу необходимых замен: в debian openssh-blacklist  не было раньше; если не делать dist-upgrade, то openssh заморозился бы на той версии, которая не использует openssl-blacklist. Т.е. надо самому выявить такие пакеты и сделать их install заново, сгенерировать новые ключи и т.п.

Видимо, это более походящий стиль для hard production сервер?

----------

## zvn

 *_Sir_ wrote:*   

> Если же вы хотите делегировать ответственность на кого-то, пожалуйста, к вашим услугам большой набор "готовых" решений Red Hat, Sun Microsystems, AIX IBM, Novell, Microsoft наконец.

 

Дело не в том, что я хочу делегировать. Я не могу уйти от использования Oracle Database, к примеру. И исходя из Ваших слов, я делаю вывод, что для использования коммерческого ПО, сделанного для Linux, мне лучше выбрать коммерческий дистрибутив (в случае Oracle Database это RHEL, SLES, OEL), т.к. в этом случае они между собой без меня договорятся с Oracle (это не делегирование, я не могу быть каплей масла во взаимодействии между их шестерёнками), а в случае, если я не буду использовать коммерческое ПО, это может быть Gentoo, Debian, FreeBSD и т.д.

----------

## _Sir_

 *zvn wrote:*   

> Я не могу уйти от использования Oracle Database, к примеру.

 Вот с этого и надо начинать, а не напускать туману  :Smile:  Здесь, в настоящее время, существует только два пути.

1) Самому принимать решения и положить на Оракл (в смысле, на то, что они, якобы, будут решать ваши проблемы, только потому, что вы изволили приобрести лицензию и/или подписку о техподдержке.) Это в большинстве случаев -- мнимое превосходство. Хотя в реальных случаях может оказаться полезным. Короче, это как страховой полис -- иметь его вы обязаны, но выплатят ли вам вообще какие-нибудь деньги -- это бооооольшой вопрос. 

2) Закрыть глаза и храбро затолкать голову в асфальт, прикрыв пушистым хвостом из красивых имен задницу. Оракл сертифицировал RHELL, Red Hat сертифицировал железо, и далее, и протчее. Это бизнес, и способ выжать из вас деньги, при этом, заметьте, ограничиваясь ничего физически не стоящими гарантиями. Эта бизнес-политика прослеживается во многих отраслях. 

Есть промежуточный вариант  :Smile:  Взять то железо, которое экономически целесообразно, даже если это крутая железяка, поставить внизу то, чем можно управлять, по крайней мере в обозримом будущем, и далее, с помощью вот этого безобразия интегрировать то, что будет угодно воротилам от IT и неумолимым боссам. 

Разумеется, через пару-тройку лет все может кардинально измениться, а системы расчитанные на применения оракла, обычно эксплуатируются дольше. Ну и что тогда? Когда вы лишили себя возможностей и отдались монополисту?  :Smile: 

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

----------

## _Sir_

 *fank wrote:*   

> тут, на мой взгляд, есть один довольно важный момент, который упускается из виду
> 
> в случае бинарных дистрибутивов политика dist upgrade (в терминологии Debian) насколько мне известно не сильно распространена

 Если честно, то я вообще не понимаю, как умудряются обновлять бинарные дистрибутивы. Одно дело на кластере под одной версией gcc, libtool, glibc и проч. собрать весь новый дистр с последующей перестановкой его  :Smile: , а кто не сделал /usr/local на отдельном девайсе -- я не виноват, и другое -- кусочные заплаты отдельных пакетов. Которые не могут быть проверены мэйнтенером на предмет работы в конкретной установленной системе.

 *fank wrote:*   

> по крайней мере, нужно быть психом, чтобы делать такое на hard production сервере

 Ну, если заранее не подумать о том, что сервера весьма желательно виртуализировать, причем тем меньше думать, чем бесперебойнее он должен работать  :Smile:  то таки да. В случае с виртуализацией можно относительно спокойно мигрировать прозрачно для пользователей. Хотя, может быть и другие решения существуют.

 *fank wrote:*   

> теперь предлагаю поразмыслить над ситуацией
> 
>  *Quote:*   Никто не мешает поставить сервак на узкую задачу и забыть о нем на пару лет, ничего там не делая. 
> 
> сколько нервов понадобится, чтобы привести систему после пары лет простоя в актуальное состояние?
> ...

 Такие серваки вполне имеют место быть в практике, и как правило для них день простоя ( в выходной или выходные/праздники) некритичен. Поэтому можно спокойно переустановить бинарный дистр, и заняться настройкой и доделкой того, что требовалось ранее, строго по утвержденному списку  :Smile:  В этом случае большой разницы нет, и даже бинарь имеет преимущество по времени установки.

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

Еще смешнее -- купили новый принтер, а старый cups его не поддерживает. Принтер разумеется подключен к серваку, кто же покупает принт-серверы, особенно от HP?  :Smile: 

Новый cups пришлось собирать, а он глючит. Выясняется, что под той версией девелоперских инструментов он и не должен собираться. Заменили девинструмент. (Это отдельная песня в бинарных дистрах) Далее, cups собрался и установился, ура! Но теперь он не дружит с самбой. Точнее, странно глючит. И так далее... Поэтому подход Gentoo в поддержании целостности системы и средств ее регенерации/воспроизводства, хотя и кажется долгим, но дает реальные преимущества -- затраты времени поддаются оценке, и мы можем брать на себя смелость ответить на самый непростой в бизнесе вопрос: Когда?

----------

