[devel] Бага (формально) может и нет, а вот проблема есть!

[devel] Бага (формально) может и нет, а вот проблема есть!

[Dmitriy M. Maslennikov]

8 января 2009 г. 22:30 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
> Twas brillig at 22:28:54 08.01.2009 UTC+03 when syatskevich@mail.ru did gyre and gimble:
>  SNY> За последние полгода (!!!) мне второй (!!!) раз удалось загрузить
>  SNY> ядро из серии std-def (2.6.27-std-def-alt8 с последним udev).
>
> Баги висят? Нет багов - нет проблемы.
Ну что это за отношение? Уже столько раз встречаю эту фразу здесь. Я
конечно могу понять мантейнера, который собрал пакет для себя, закинул
его в Сизиф, чтобы на флешке с собой не насить и отмахивается от
остальных как может. Но остальные то? Вы думаете, что человек
обманывает, или это у вас принцип такой: "без багзиллы и смотреть ни
на что не буду"? Конечная цель какая, получить стабильный хорошо
работающий продукт, который самих не подведет, и друзьям/фирме
поставить не стыдно? Так вот такие проблемы это ценнейшие образцы
странного поведения системы. И что, что человеку лень написать багу?
Человеку, может, проще Ubuntu поставить, чем со всякими багзиллами
разбираться! А вот мантейнеру надо за такое цепляться, улучшать
качество своего продукта. Тем более, если он за это получает зарплату.
А если пакет вообще не интересен, то зачем его вообще держать за
собой?

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Aleksey Novodvorsky]

8 января 2009 г. 22:50 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
> 8 января 2009 г. 22:30 пользователь Mikhail Gusarov
> <dottedmag@altlinux.org> написал:
>> Twas brillig at 22:28:54 08.01.2009 UTC+03 when syatskevich@mail.ru did gyre and gimble:
>>  SNY> За последние полгода (!!!) мне второй (!!!) раз удалось загрузить
>>  SNY> ядро из серии std-def (2.6.27-std-def-alt8 с последним udev).
>>
>> Баги висят? Нет багов - нет проблемы.
> Ну что это за отношение? Уже столько раз встречаю эту фразу здесь. Я
> конечно могу понять мантейнера, который собрал пакет для себя, закинул
> его в Сизиф, чтобы на флешке с собой не насить и отмахивается от
> остальных как может. Но остальные то? Вы думаете, что человек
> обманывает, или это у вас принцип такой: "без багзиллы и смотреть ни
> на что не буду"? Конечная цель какая, получить стабильный хорошо
> работающий продукт, который самих не подведет, и друзьям/фирме
> поставить не стыдно? Так вот такие проблемы это ценнейшие образцы
> странного поведения системы. И что, что человеку лень написать багу?
> Человеку, может, проще Ubuntu поставить, чем со всякими багзиллами
> разбираться! А вот мантейнеру надо за такое цепляться, улучшать
> качество своего продукта. Тем более, если он за это получает зарплату.
> А если пакет вообще не интересен, то зачем его вообще держать за
> собой?

Давайте хоть в devel@ не будем проповеди читать. Как юзер, честное слово!
Речь идет о ядре, об очень сложном и вечно проблемном пакете. Уж
разработчики-то могут помочь мейнтейнеру не бегать по всем спискам и
форумам, а сосредоточиться на bugzilla?

Rgrds, Алексей

>
> --
> Dmitriy M. Maslennikov
> rlz@etersoft.ru
> rlz@altlinux.org
> maslennikovdm@gmail.com
> master@armory.ru
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

* Dmitriy M. Maslennikov <maslennikovdm@> [090108 22:58]:
> > Баги висят? Нет багов - нет проблемы.
> Ну что это за отношение?
"Дорогие  ученые.  У меня который год в подполе происходит
подземный стук.  Объясните, пожалуйста, как он происходит".

Можно сколько угодно орать в рассылках и на форумах что "foo
совсем нерабочий", пользы от этого не будет никакой.  Только
минус к репутации орущего.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Michael Shigorin]

On Thu, Jan 08, 2009 at 11:02:58PM +0300, Aleksey Novodvorsky wrote:
> >> Баги висят? Нет багов - нет проблемы.
> > Ну что это за отношение? Уже столько раз встречаю эту фразу
> > здесь. Я конечно могу понять мантейнера, который собрал пакет
> > для себя, закинул его в Сизиф, чтобы на флешке с собой не
> > насить и отмахивается от остальных как может.

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

> > А вот мантейнеру надо за такое цепляться, улучшать качество
> > своего продукта. Тем более, если он за это получает зарплату.

Интересно, какая часть сизифа хоть как-то прикрыта зарплатой...
(а какая -- собирается на совесть; и каково пересечение)

> > А если пакет вообще не интересен, то зачем его вообще держать
> > за собой?

Мне "вообще неинтересны" >2/3 пакетов, которые за мной числятся.
Последний раз отчёт делал весной 2007 при подготовке ALS4.0.

Их за собой не держу и перевесил на nobody@; забрали целых
несколько штук.  А изредка собирать "по инерции" особенно не
напрягает, поскольку для большинства выживших пакетов это
несколько минут на каждый.

> Давайте хоть в devel@ не будем проповеди читать.

Правильно, будем продолжать писать отповеди в других местах.
Ну и http://www.opennet.ru/openforum/vsluhforumID3/47287.html#62

> Уж разработчики-то могут помочь мейнтейнеру не бегать по всем
> спискам и форумам, а сосредоточиться на bugzilla?

Или: уж разработчики-то могли бы и проникнуться разницей.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Sergey N. Yatskevich]

В Чтв, 08/01/2009 в 23:08 +0300, Alexey I. Froloff пишет:
> * Dmitriy M. Maslennikov <maslennikovdm@> [090108 22:58]:
> > > Баги висят? Нет багов - нет проблемы.
> > Ну что это за отношение?
> "Дорогие  ученые.  У меня который год в подполе происходит
> подземный стук.  Объясните, пожалуйста, как он происходит".
"При загрузке ядро виснет на Populating /dev ..."
"Ядро WKS - работает"

"При удалении modules.dep* один раз можно загрузиться, но при
этом весь проц жрёт kacpi_nofity ..."
"Ядро WKS - работает"

"При повторной перезагрузке ядро опять виснет на Populating /dev ..."
"А ядро WKS любой версии - работает"

...

Это вы считаете синонимом "Дорогие ученые. У меня который год в
подполе происходит подземный стук. Объясните, пожалуйста, как он
происходит"? Или я сам должен догадываться, чего Вам ещё не хватает?

> Можно сколько угодно орать в рассылках и на форумах что "foo
> совсем нерабочий", пользы от этого не будет никакой.  Только
> минус к репутации орущего.
Хм, а где это я "орал", что ядро _совсем_ не рабочее? Я вообще-то
пытался в меру своего разумения описать проблему и как-то решить
её. Просто ядро - не мой профиль и я не могу ничего с ним сделать
в одиночку, особенно в нетривиальных случаях.

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

P.S. для тех кто в танке ещё раз повторяю - В WKS ЛЮБОЙ ВЕРСИИ ВСЁ
     РАБОТАЕТ!!!!! Или для Вас не только баг без багзиллы не существует,
     но и рядом работающего решения, если оно не Сизифе (по крайней
     мере именно так мне ответил господин Иноземцев - "в Сизифе нет
     такого ядра - WKS")? Или я сам должен искать 3 отличия в ваших
     конфигурациях и патчах?

P.P.S. я осмелюсь высказать крамольное предположение, но по моему всё
       дело в SYSFS_DEPRECATED. Правда я могу и ошибаться. Но если вы
       мне предложите самому разобраться во всех зависимостях опций
       ядра, включить обратно то, что мне нужно и пересобрать, то пока
       есть WKS я пожалуй откажусь. В конце концов это же open source,
       есть из чего выбрать :-).

-- 
Sergey N. Yatskevich <syatskevich@mail.ru>

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Pavlov Konstantin]

[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

On Thu, Jan 08, 2009 at 10:50:15PM +0300, Dmitriy M. Maslennikov wrote:
> 8 января 2009 г. 22:30 пользователь Mikhail Gusarov
> <dottedmag@altlinux.org> написал:
> > Twas brillig at 22:28:54 08.01.2009 UTC+03 when syatskevich@mail.ru did gyre and gimble:
> >  SNY> За последние полгода (!!!) мне второй (!!!) раз удалось загрузить
> >  SNY> ядро из серии std-def (2.6.27-std-def-alt8 с последним udev).
> >
> > Баги висят? Нет багов - нет проблемы.
> Ну что это за отношение? Уже столько раз встречаю эту фразу здесь. Я
> конечно могу понять мантейнера, который собрал пакет для себя, закинул
> его в Сизиф, чтобы на флешке с собой не насить и отмахивается от
> остальных как может. Но остальные то? Вы думаете, что человек
> обманывает, или это у вас принцип такой: "без багзиллы и смотреть ни
> на что не буду"?

У меня помимо ALT еще есть обязанности (и желания и настроение) заниматься
кое-чем другим.  Как Вы думаете, способствует ли протоколирование багов в
багзилле запоминанию мной того, что у меня в пакетах есть ошибки?  А
упоминание в рассылках, которые я читаю очень изредка и выборочно?  А
личная переписка / IRC в течение РАБОЧЕГО времени?

> Конечная цель какая, получить стабильный хорошо работающий продукт,
> который самих не подведет, и друзьям/фирме поставить не стыдно?

Это интересный вопрос, например я не могу однозначно на него ответить.

> Так вот такие проблемы это ценнейшие образцы странного поведения
> системы. И что, что человеку лень написать багу?
> Человеку, может, проще Ubuntu поставить, чем со всякими багзиллами
> разбираться!

Мне такой пользователь не интересен.

> А вот мантейнеру надо за такое цепляться, улучшать качество своего
> продукта.

Надо, по мере им самим обнаружения багов и ФОРМАЛИЗОВАННЫХ отзывов от
пользователей.

> Тем более, если он за это получает зарплату.

Интересно, сколько у нас таких мантейнеров, не считая eter, mmagic и alt?

> А если пакет вообще не интересен, то зачем его вообще держать за
> собой?

Да некому их отдать обычно.

-- 
<henker> а что такое RSS, там на баш.орг есть
<aphlux> henker: формат ленты новостей для читалок и т.п.
<wRAR> henker: фгугль
<henker> aphlux: я так и подумал
<henker> wRAR: ага, спасиба :)
 * raorn .oO( RSS - Resident Set Size )

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Michael Shigorin]

On Fri, Jan 09, 2009 at 12:29:30AM +0300, Pavlov Konstantin wrote:
> > Тем более, если он за это получает зарплату.
> Интересно, сколько у нас таких мантейнеров, не считая eter,
> mmagic и alt?

В Media Magic никто не получал зарплату именно за пакеты,
насколько мне известно.  Хотя для решения задач по проектам
исправление/улучшение/сборка новых пакетов регулярно требуется.

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

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

* Sergey N. Yatskevich <syatskevich@> [090109 00:26]:
> "При загрузке ядро виснет на Populating /dev ..."
> Это вы считаете синонимом "Дорогие ученые.
Это уже было вытянуто клещами.

> > Можно сколько угодно орать в рассылках и на форумах что "foo
> > совсем нерабочий", пользы от этого не будет никакой.  Только
> > минус к репутации орущего.
> Хм, а где это я "орал", что ядро _совсем_ не рабочее?
Выше по треду.

> P.S. для тех кто в танке ещё раз повторяю - В WKS ЛЮБОЙ ВЕРСИИ ВСЁ
>      РАБОТАЕТ!!!!
Это мягко говоря неправда.  Например у меня (а также у hiddenman
и legion) buildreq на wks ядре работает на _порядок_ медленнее.
Я же от этом не кричу.  Просто переехал на std-def.  На котором
кстати наконец-то нормально заработал Suspend To RAM.  В отличие
от.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Aleksey Novodvorsky]

9 января 2009 г. 2:05 пользователь Alexey I. Froloff
<raorn@altlinux.ru> написал:
> * Sergey N. Yatskevich <syatskevich@> [090109 00:26]:
>> "При загрузке ядро виснет на Populating /dev ..."
>> Это вы считаете синонимом "Дорогие ученые.
> Это уже было вытянуто клещами.
>
>> > Можно сколько угодно орать в рассылках и на форумах что "foo
>> > совсем нерабочий", пользы от этого не будет никакой.  Только
>> > минус к репутации орущего.
>> Хм, а где это я "орал", что ядро _совсем_ не рабочее?
> Выше по треду.
>
>> P.S. для тех кто в танке ещё раз повторяю - В WKS ЛЮБОЙ ВЕРСИИ ВСЁ
>>      РАБОТАЕТ!!!!
> Это мягко говоря неправда.  Например у меня (а также у hiddenman
> и legion) buildreq на wks ядре работает на _порядок_ медленнее.
> Я же от этом не кричу.  Просто переехал на std-def.  На котором
> кстати наконец-то нормально заработал Suspend To RAM.  В отличие
> от.

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

Rgrds, Алексей

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

On Fri, Jan 09, 2009 at 12:29:30AM +0300, Pavlov Konstantin wrote:

>> Тем более, если он за это получает зарплату.
PK> Интересно, сколько у нас таких мантейнеров, не считая eter, mmagic и alt?

Де-факто поддержка asterisk'овского хозяйства и всего что мне нужно для
серверов в сизифе -- делается в рабочее время. В Сейрос. И вопрос принятия
мантейнера на зарплату чтобы снять с меня часть нагрузки по этому поводу
висит в воздухе уже давно.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

On Thu, Jan 08, 2009 at 11:37:09PM +0200, Michael Shigorin wrote:

MS> Из других фирм есть как минимум партнёры по школьному пилоту.
MS> Правда, мне продолжает казаться, что пакеты "от себя", а не
MS> "по работе" являются наиболее качественно поддерживаемыми.

Думаю что наиболее качественными должны быть пакеты сисадминов :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага (формально) может и нет, а вот проблема есть!

[Michail Yakushin]

Alexey I. Froloff wrote:
> * Sergey N. Yatskevich <syatskevich@> [090109 00:26]:
>> "При загрузке ядро виснет на Populating /dev ..."
>> Это вы считаете синонимом "Дорогие ученые.
> Это уже было вытянуто клещами.
> 
>>> Можно сколько угодно орать в рассылках и на форумах что "foo
>>> совсем нерабочий", пользы от этого не будет никакой.  Только
>>> минус к репутации орущего.
>> Хм, а где это я "орал", что ядро _совсем_ не рабочее?
> Выше по треду.
> 
>> P.S. для тех кто в танке ещё раз повторяю - В WKS ЛЮБОЙ ВЕРСИИ ВСЁ
>>      РАБОТАЕТ!!!!
> Это мягко говоря неправда.  Например у меня (а также у hiddenman
> и legion) buildreq на wks ядре работает на _порядок_ медленнее.
> Я же от этом не кричу.  Просто переехал на std-def.  На котором
> кстати наконец-то нормально заработал Suspend To RAM.  В отличие
> от.
> 
По поводу std vs wks. Я думаю что мало того что wks полезно, но и должно
быть в сизифе, чтобы можно было проводить так сказать дифиренциальную
диагностику, что с ним делать удобно потому что там содержаться
эксперементальные пачи. В std нет эксперементальных пачей, потому что на
мой взгляд оно так будет стабильнее(В целом работать)
Так что давайте на всё что не было поправлено мгновенно вешать баги, в
случае с ядром будет полезно указать что на wks такой-то версии(это
важно) работает.

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Alexey Morozov]

Здравствуйте!

On Friday 09 January 2009 01:50:15 Dmitriy M. Maslennikov wrote:
> 8 января 2009 г. 22:30 пользователь Mikhail Gusarov
> > Баги висят? Нет багов - нет проблемы.
>
> Ну что это за отношение? Уже столько раз встречаю эту фразу здесь.

Дмитрий, это просто формализация работы. Если Вам нужна неофициальная помощь - 
добро пожаловать в IRC, можно спросить в Jabber. Только нужно помнить, что 
помощь, получаемая таким образом - это добрая воля собравшихся, наличие у них 
готовых знаний по интересующей Вас теме, свободного времени и, хе-хе, 
хорошего настроения (привет wRAR'у! :) ). Если Вам не помогли должным образом 
после Вашего крика души в IRC, чате или списке рассылки - это _Ваша_ 
проблема, ничья более.

Если же Вас не устраивает подобная зыбкость, то самое время перейти к более 
формальным отношениям ;) Как гласит известная шутка, у товарищей курсантов 
дырявые головы, и поэтому им требуется блокнот. Или два, как у меня. 
Блокнотом мэнтейнера является багзилла. По ней можно отследить, кто когда 
кому говорил и что делал, и затем привлечь проштрафившихся к ответственности. 

Разумеется, багзильный воркфлоу не является идеальным. Более того, для репорта 
инцидентов она не слишком пригодна, имеется определенный бардак со статусами, 
до последнего времени отсутствовало такое понятие как временная шкала (сейчас 
есть "дедлайн" но это не совсем то, чего хочется) и т.п. Но, как говорится, 
иногда и дворник^W^W^W что есть, то есть, и для _разработки_ программного 
продукта или дистрибутива она неплоха.

> странного поведения системы. И что, что человеку лень написать багу?
> Человеку, может, проще Ubuntu поставить, чем со всякими багзиллами
> разбираться!

Вам кажется, что в Убунту нет багов? Дак я даже адресочек подскажу, 
https://bugs.launchpad.net

Но я так скажу: некоторым людям, да, правильнее поставить Ubuntu. У некоторых, 
вроде меня, она даже стоит или стояла. Но, по секрету Вам скажу, Ubuntu 
неидеальна и, попользовав её в качестве десктопа пару месяцев, после слёта 
файлухи я поставил ALD 4.1. Он тоже, разумеется, неидеален, но интересующие 
именно меня вещи там собраны более адекватно моим нуждам, а то, что меня не 
устраивает я могу перетереть с уважаемыми мэнтейнерами (отдельное спасибо 
lav@ !)

> А вот мантейнеру надо за такое цепляться, улучшать 
> качество своего продукта. Тем более, если он за это получает зарплату.
> А если пакет вообще не интересен, то зачем его вообще держать за
> собой?
Я Вам по секрету скажу: девелУперы - такие уроды! Им всем погонщик требуется, 
что тем крокодилам из известного анекдота. И, возвращаясь к теме багзиллы, 
репортя баги, Вы даёте в руки погонщиков такую палку, против которой самые 
джастфофанистые не устоят. Так что, репортьте баги и наблюдайте за экзекуцией 
особо неповоротливых!

С уважением,
Алексей Морозов,
начинающий Йоорол-Гуй.

P.S. Вышесказанное не отражает точку зрения никого, включая автора :)

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Dmitriy M. Maslennikov]

9 января 2009 г. 11:35 пользователь Alexey Morozov <morozov_ml@ngs.ru> написал:
> Дмитрий, это просто формализация работы. Если Вам нужна неофициальная помощь -
> добро пожаловать в IRC, можно спросить в Jabber. Только нужно помнить, что
> помощь, получаемая таким образом - это добрая воля собравшихся, наличие у них
> готовых знаний по интересующей Вас теме, свободного времени и, хе-хе,
> хорошего настроения (привет wRAR'у! :) ). Если Вам не помогли должным образом
> после Вашего крика души в IRC, чате или списке рассылки - это _Ваша_
> проблема, ничья более.
Я не о себе, как вы подумали. Я о положении дел вообще.

> Если же Вас не устраивает подобная зыбкость, то самое время перейти к более
> формальным отношениям ;) Как гласит известная шутка, у товарищей курсантов
> дырявые головы, и поэтому им требуется блокнот. Или два, как у меня.
> Блокнотом мэнтейнера является багзилла. По ней можно отследить, кто когда
> кому говорил и что делал, и затем привлечь проштрафившихся к ответственности.
Какая ответственность, если все делается for fun?

> Вам кажется, что в Убунту нет багов? Дак я даже адресочек подскажу,
> https://bugs.launchpad.net
Есть, я о том, что люди выбирают то ПО, где багов меньше. И меньше их
сейчас в Винде. И надо стремиться их обогнать, тогда и люди
потянуться.

> Но я так скажу: некоторым людям, да, правильнее поставить Ubuntu. У некоторых,
> вроде меня, она даже стоит или стояла. Но, по секрету Вам скажу, Ubuntu
> неидеальна и, попользовав её в качестве десктопа пару месяцев, после слёта
> файлухи я поставил ALD 4.1. Он тоже, разумеется, неидеален, но интересующие
> именно меня вещи там собраны более адекватно моим нуждам, а то, что меня не
> устраивает я могу перетереть с уважаемыми мэнтейнерами (отдельное спасибо
> lav@ !)
Не расказывайте мне про Ubuntu, я ее видел и много. Она не идеально,
но на железо явно лучше ставиться, что и обуславливает ее гораздо
большую популярнось. Альт же надо сначала немного напильником, что
совершенно не подходит для новичков.

Впрочем, речь не о том, а об отношении к неформализованным сообщениям
о багах. Вместо уместного в этих случаях предложения переместиться в
багзиллу и продолжить там, имеем резкое "Нет бага, нет проблемы!".
Тогда как именно тот факт, что мантейнер не добился заведения бага
проблемой и является. При этом наличие проблемы с наличием или
отсутствием бага никак не связано. Проблема просто есть! И это надо
осознавать, а не кидаться никчемными фразами. У нас вообще бюрократия
в чести: нет заявления - нет преступления. Нет официальной бумаги - ни
один чиновник не почешется. Я же хотел показать, что это просто
халатное отношение к своей работе. При этом я понимаю, что удобнее баг
видеть в багзилле, но его отсутствие совсем НЕ ПОВОД от него
отмахиваться, как будто его не существует. Просто не надо судить о
работе только по формальным критериям, как уважаемый Led пытается
делать в соседней ветке.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Dmitriy M. Maslennikov]

В догонку:

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

Вот пишет кто-то про то, что баг о котором он давно писал все еще на
месте, а ему вместо того, чтобы честно сказать, что я забыл, поскольку
вы, уважаемый баг не завели, давайте напомните про проблему и я
займусь заявляют, что проблемы у мантейнера и вовсе нет, поскольку не
все бланки были правильно заполнены. Ну не бюрократизм ли? А вот
наказывать мантейнеров за нерасторопность или еще что не стоит.
Особенно джастфофанщиков. Скорее надо упростить NMU, чтобы "собак на
сене" поубавилось, но это тоже совсем другая проблема.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Dmitriy M. Maslennikov]

9 января 2009 г. 12:11 пользователь Dmitriy M. Maslennikov
<maslennikovdm@gmail.com> написал:
> Просто не надо судить о
> работе только по формальным критериям, как уважаемый Led пытается
> делать в соседней ветке.
Да, прошу извинить Led'а за необоснованные притензии, я его спутал с кем-то.

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

[devel] [JT] Re: Бага ( формально ) может и нет , а вот проблема есть!

[Mykola S. Grechukh]

2009/1/9 Dmitriy M. Maslennikov <>:
> Тогда как именно тот факт, что мантейнер не добился заведения бага
> проблемой и является. При этом наличие проблемы с наличием или
> отсутствием бага никак не связано. Проблема просто есть! И это надо
> осознавать, а не кидаться никчемными фразами. У нас вообще бюрократия
> в чести: нет заявления - нет преступления. Нет официальной бумаги - ни
> один чиновник не почешется. Я же хотел показать, что это просто
> халатное отношение к своей работе. При этом я понимаю, что удобнее баг
> видеть в багзилле, но его отсутствие совсем НЕ ПОВОД от него
> отмахиваться, как будто его не существует.

http://bash.org.ru/quote/268537

Re: [devel] [JT] Re: Бага ( формально ) может и нет , а вот проблема есть!

[Dmitriy M. Maslennikov]

9 января 2009 г. 15:12 пользователь Mykola S. Grechukh
<nick.grechukh@gmail.com> написал:
> http://bash.org.ru/quote/268537
Немного юмора не повредит )

Просто ситуация в рассылке накалена до придела. Давайте просто будем
вежливее и внимательнее друг к другу. Ну и чиним баги, чиним!

-- 
Dmitriy M. Maslennikov
rlz@etersoft.ru
rlz@altlinux.org
maslennikovdm@gmail.com
master@armory.ru

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

* Dmitriy M. Maslennikov <maslennikovdm@> [090109 15:16]:
> Вместо уместного в этих случаях предложения переместиться в
> багзиллу и продолжить там, имеем резкое "Нет бага, нет
> проблемы!".
Подобные предложения звучат по десять раз на дню последние пол
года точно.  Или это надо говорить _каждому_ "неформальному
репортеру"?

> Тогда как именно тот факт, что мантейнер не добился заведения
> бага проблемой и является.
Нет.  Я сам сколько раз пинал мантейнеров в IRC и Jabber, на что
очень часто получал ответ "мне щас некогда, повесь багу, а то
забуду".  Мне бывало лень вешать баги и мантейнеры про них
забывали.  Кто виноват?  Только я.

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

А ещё бывает, что пакет мантейнит команда разработчиков.  Как они
будут узнавать о таких "неформальных багах"?

P.S. Это всё напоминает историю с внедрением git/gear.  "Мне лень
разбираться, я так привык", а на самом деле это очень даже удобно
в смысле коллективной разработки.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Friday 09 January 2009 13:32:31 Dmitriy M. Maslennikov wrote:
> 9 января 2009 г. 12:11 пользователь Dmitriy M. Maslennikov
>
> <maslennikovdm@gmail.com> написал:
> > Просто не надо судить о
> > работе только по формальным критериям, как уважаемый Led пытается
> > делать в соседней ветке.
>
> Да, прошу извинить Led'а за необоснованные притензии, я его спутал с
> кем-то.

Похоже на то:)

Я вообще здесь формальных притензий к мейнтейнеру ядра не высказывал - я всего 
лишь ответил на пост/вопрос mike'а (AFAIR относительно того, почему я не 
использую (не могу использовать) std-def из сизифа). Меня же (почему-то) 
обвинили сначала в "наездах", а теперь ещё и в том, что я кого-то "сужу по 
формальным критериям":)
Поверьте, я немножко могу судить о том, насколько сложно мейнтейнить ядро, 
поэтому "судить", "обвинять", "наезжать" - это не про меня:) Я могу быть 
чем-то недоволен, но уж право быть "чем-то недовольным" прошу всё же мне 
оставить:)

В ситуации с ядром я могу (совершенно без ирони) винить только себя. Потому 
как в том, что я не могу найти время, чтобы собрать себе свежее ядро (или 
попытаться потестить/пофиксить std-def и предложить исправления мейнтейнеру) 
виноват только я лично.
2.6.22, которое уменя достаточно отлажено и "вылизано" и полностью меня 
устраивало до недавнего времени, к сожалению, не поддерживает Ethernet на 
свежепредоставленной мне машине. Сбэкпортить forcedeth поновее на 2.6.22 я 
пока тоже времени не нашёл, а теперь и не знаю - стОит ли, потому 
как "обрадовали", что всё, что ниже 2.6.25 в сизифе 
принудительно "обрубается" :( Вот этим я действительно "недоволен", потому 
что причин для этого я НЕ ВИЖУ. И (рискуя опять нарваться на обвинения в мой 
адрес) считаю это ДЕСТРУКТИВНЫМИ действиями. Если я неправ - прошу 
аргументировать.

-- 
Led

Re: [devel] [JT] Бага ( формально ) может и нет , а вот проблема есть!

[Alexey Morozov]

On Friday 09 January 2009 15:11:29 Dmitriy M. Maslennikov wrote:
> 9 января 2009 г. 11:35 пользователь Alexey Morozov <morozov_ml@ngs.ru> 
написал:
> > свободного времени и, хе-хе, хорошего настроения (привет wRAR'у! :) ).
> > Если Вам не помогли должным образом после Вашего крика души в IRC, чате
> > или списке рассылки - это _Ваша_ проблема, ничья более.
>
> Я не о себе, как вы подумали. Я о положении дел вообще.

Обсуждать "положение дел вообще", без привязки к конкретным случаям, - задача 
для меня не из лёгких, признаюсь.

> > меня. Блокнотом мэнтейнера является багзилла. По ней можно отследить, кто
> > когда кому говорил и что делал, и затем привлечь проштрафившихся к
> > ответственности.
>
> Какая ответственность, если все делается for fun?

Если всё делается for fun, то, спешу Вас разочаровать. Пытаться понять, в чём 
состоит проблема человека, который находится подчас за тысячи километров, 
имеет кривое^W очень специфическое железо, и не слишком подробен в своём 
репорте - это нифига не фан. Хуже того, это нудная, противная, а в случае 
[Альт] Линукса, - еще и часто неоплачиваемая _работа_. Неоплачиваемая, потому 
что очень много здешних людей не работают ни в ООО, ни в Компаниях - 
партнёрах ООО.

Теперь касательно ответственности. Если некто ставит перед собой и коллективом 
задачу построения некоего продукта (не очень важно, собираются ли они Линукс 
паковать или носки вязать и потом прохожим на улицах раздавать), то, 
очевидно, что этот некто должен некоим образом замотивировать сотрудников. А 
мотивация, помимо всяческих бонусов и плюшек, обязана включать в себя и 
методы принуждения, увы. Хоть бы и моральные.

Но, если честно, Вы зря воспринимаете меня так серьёзно :)

> > Вам кажется, что в Убунту нет багов? Дак я даже адресочек подскажу,
> > https://bugs.launchpad.net
>
> Есть, я о том, что люди выбирают то ПО, где багов меньше. И меньше их
> сейчас в Винде. И надо стремиться их обогнать, тогда и люди
> потянуться.

Ох, на языке, конечно, вертятся вопросы, которые я обычно задаю тем, кто 
считает, что Линукс должен кого-то догонять, в особенности, по багам, но 
обсуждение этих вопросов лучше проводить в другом месте.


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

Охх, я думаю, в этом месте мы можем уйти в глупую и нескончаемую дискуссию.


> Впрочем, речь не о том, а об отношении к неформализованным сообщениям
> о багах. Вместо уместного в этих случаях предложения переместиться в
> багзиллу и продолжить там,

"И так - 18 раз, Ваша честь!"

> имеем резкое "Нет бага, нет проблемы!". 
> Тогда как именно тот факт, что мантейнер не добился заведения бага
> проблемой и является. При этом наличие проблемы с наличием или отсутствием
> бага никак не связано.  Проблема просто есть!

Строго говоря, в правильно и строго организованном воркфлоу  общение с 
разгневанными пользователями - это не задача девелУпера/мэнтейнера. Здесь уже 
привели башорговую цитату. Не сказать, чтобы я был большим поклонником этого 
ресурса, но в данном конкретном случае ситуация вполне знакомая. Только 
вот "понимающие директора" с той стороны встречаются отнюдь не часто.

Но, как говорится, в рамках OSS имеем то, что имеем. Однако даже то, что 
девелопер/мэнтейнер и его жертвы предоставлены сами себе не отменяет 
некоторых формальных сторон общения, особенно в проблемных ситуациях. 
Совершенно очевидно, что заставлять девелопера прислушиваться ко всем 
возможным источникам горестных возгласов - это не ценить его время и, 
следовательно, не уважать его. Любое более-менее содержательное общение надо 
переводить в багзиллу.

> И это надо  
> осознавать, а не кидаться никчемными фразами. У нас вообще бюрократия
> в чести: нет заявления - нет преступления.

Не совсем так, дело может быть заведено прокураторой по /собственной 
инициативе/, но это оффтопик.

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

> Я же хотел показать, что это просто халатное отношение к своей работе.
Нет, это просто соблюдение формальных правил собственной деятельности.

> При этом я понимаю, что удобнее баг видеть в багзилле, но его отсутствие
> совсем НЕ ПОВОД от него отмахиваться, как будто его не существует.
Отсутствие бага в багзилле - это отсутствие повода _работать_ по данной 
проблеме. Присоветовать чего-нибудь - да, посочувствовать - запросто, лично 
для меня это иногда ещё и повод поглумиться над некоторыми неудачниками ;)

> Просто не надо судить о работе только по формальным критериям, как уважаемый
> Led пытается делать в соседней ветке.

Вероятнее всего, имеется в виду Михаил Гусаров. Что ж, могу сказать, что 
ростки проклятой корпороидности пустили корни не только в меня :) Просто ему, 
как и мне кажется, что начиная с некоторого уровня без формализации рабочего 
процесса продуктивная деятельность группы людей _физически невозможна_.

С уважением,
А. Морозов.

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Led пишет:
<skip>
> 
> В ситуации с ядром я могу (совершенно без ирони) винить только себя. Потому 
> как в том, что я не могу найти время, чтобы собрать себе свежее ядро (или 
> попытаться потестить/пофиксить std-def и предложить исправления мейнтейнеру) 
> виноват только я лично.
> 2.6.22, которое уменя достаточно отлажено и "вылизано" и полностью меня 
> устраивало до недавнего времени, к сожалению, не поддерживает Ethernet на 
> свежепредоставленной мне машине. Сбэкпортить forcedeth поновее на 2.6.22 я 
> пока тоже времени не нашёл, а теперь и не знаю - стОит ли, потому 
> как "обрадовали", что всё, что ниже 2.6.25 в сизифе 
> принудительно "обрубается" :( Вот этим я действительно "недоволен", потому 
> что причин для этого я НЕ ВИЖУ. И (рискуя опять нарваться на обвинения в мой 
> адрес) считаю это ДЕСТРУКТИВНЫМИ действиями. Если я неправ - прошу 
> аргументировать.

Ну так что делать - udev действительно переодически (с новой версией) 
обрубает старые ядра... приходится мириться и жевать этот кактус.

Хорошо, что мы хоть ядро 2.4.x выкинули из Sisyphus...

Для старых ядер, надеюсь, есть branch/5.0, где вроде как всё по прежнему.

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

...
> Ну так что делать - udev действительно переодически (с новой версией)
> обрубает старые ядра... приходится мириться и жевать этот кактус.
udev это давно уже такая часть ядра. для старых ядер есть архив сизифа

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
> ...
> > Ну так что делать - udev действительно переодически (с новой версией)
> > обрубает старые ядра... приходится мириться и жевать этот кактус.
> udev это давно уже такая часть ядра. для старых ядер есть архив сизифа

Ну, тогда может стоит поставить там зависимость на версию kernel? Может
энтропия снизится.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Kirill A. Shutemov пишет:
> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
>> ...
>>> Ну так что делать - udev действительно переодически (с новой версией)
>>> обрубает старые ядра... приходится мириться и жевать этот кактус.
>> udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
> 
> Ну, тогда может стоит поставить там зависимость на версию kernel? Может
> энтропия снизится.

Это сложно. В системе может стоять несколько ядер, да и у нас не принято 
делать зависимость у userspace на kernel.

будут проблемы при dist-upgrade - влетит первое попавшееся ядро (по 
алфавиту, если не ошибаюсь).

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
> > ...
> >
> > > Ну так что делать - udev действительно переодически (с новой версией)
> > > обрубает старые ядра... приходится мириться и жевать этот кактус.
> >
> > udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
>
> Ну, тогда может стоит поставить там зависимость на версию kernel? Может
> энтропия снизится.

на какой kernel из?

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

On Fri, Jan 09, 2009 at 11:33:04PM +0300, Anton Farygin wrote:
> Kirill A. Shutemov пишет:
> > On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
> >> ...
> >>> Ну так что делать - udev действительно переодически (с новой версией)
> >>> обрубает старые ядра... приходится мириться и жевать этот кактус.
> >> udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
> > 
> > Ну, тогда может стоит поставить там зависимость на версию kernel? Может
> > энтропия снизится.
> 
> Это сложно. В системе может стоять несколько ядер, да и у нас не принято 
> делать зависимость у userspace на kernel.
> 
> будут проблемы при dist-upgrade - влетит первое попавшееся ядро (по 
> алфавиту, если не ошибаюсь).

Сравнять в провах с модулями -- поставить на hold в дефолтном apt.conf.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

On Fri, Jan 09, 2009 at 11:34:37PM +0300, Valery V. Inozemtsev wrote:
> On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
> > On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
> > > ...
> > >
> > > > Ну так что делать - udev действительно переодически (с новой версией)
> > > > обрубает старые ядра... приходится мириться и жевать этот кактус.
> > >
> > > udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
> >
> > Ну, тогда может стоит поставить там зависимость на версию kernel? Может
> > энтропия снизится.
> 
> на какой kernel из?

на просто kernel. Он предоставляется(по крайней мере, должен) всеми ядрами.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kernel requirement in userspace

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

On Fri, Jan 09, 2009 at 10:46:08PM +0200, Kirill A. Shutemov wrote:
> On Fri, Jan 09, 2009 at 11:34:37PM +0300, Valery V. Inozemtsev wrote:
> > On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
> > > On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
> > > > ...
> > > >
> > > > > Ну так что делать - udev действительно переодически (с новой версией)
> > > > > обрубает старые ядра... приходится мириться и жевать этот кактус.
> > > >
> > > > udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
> > >
> > > Ну, тогда может стоит поставить там зависимость на версию kernel? Может
> > > энтропия снизится.
> > 
> > на какой kernel из?
> 
> на просто kernel. Он предоставляется(по крайней мере, должен) всеми ядрами.

Установленное ядро и работающее ядро -- это не одно и то же.
Зависимость на ядро не даёт гарантии того, что будет работать именно это
ядро.  По этой причине зависимость на ядро в userspace лишена смысла.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kernel requirement in userspace

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]


Twas brillig at 23:46:17 09.01.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:

 DVL> По этой причине зависимость на ядро в userspace лишена смысла.

А конфликт со старыми ядрами? Впрочем, это опасно, если никто не требует
"какого-нибудь" ядра :)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Friday, 09 January 2009 22:33:04 Anton Farygin wrote:
> Kirill A. Shutemov пишет:
> > On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
> >> ...
> >>
> >>> Ну так что делать - udev действительно переодически (с новой версией)
> >>> обрубает старые ядра... приходится мириться и жевать этот кактус.
> >>
> >> udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
> >
> > Ну, тогда может стоит поставить там зависимость на версию kernel? Может
> > энтропия снизится.
>
> Это сложно. В системе может стоять несколько ядер, да и у нас не принято
> делать зависимость у userspace на kernel.

А установить в систему пакет udev_X (где X - нужная версия) - вобще 
невозможно. Потому, что:
$ grep udev /usr/lib/rpm/0common-files.req.list
/etc/udev/rules.d       udev-rules

Это зачем? Что никому неповадно было нужный ему udev собрать?

> будут проблемы при dist-upgrade - влетит первое попавшееся ядро (по
> алфавиту, если не ошибаюсь).

Проблем будет значительно меньше, даже если их не решать, а просто не делать 
их искусственное старательное изготовление (как в случае с udev).

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Friday, 09 January 2009 22:34:37 Valery V. Inozemtsev wrote:
> On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
> > On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
> > > ...
> > >
> > > > Ну так что делать - udev действительно переодически (с новой версией)
> > > > обрубает старые ядра... приходится мириться и жевать этот кактус.
> > >
> > > udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
> >
> > Ну, тогда может стоит поставить там зависимость на версию kernel? Может
> > энтропия снизится.
>
> на какой kernel из?

На тот специальный Provides, который это ядро предоставит.

-- 
Led

Re: [devel] udev

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote:
[...]
> А установить в систему пакет udev_X (где X - нужная версия) - вобще 
> невозможно. Потому, что:
> $ grep udev /usr/lib/rpm/0common-files.req.list
> /etc/udev/rules.d       udev-rules
> 
> Это зачем? Что никому неповадно было нужный ему udev собрать?

А чем 0common-files.req.list мешает кому-то собрать нужный ему udev?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Kirill A. Shutemov пишет:
> On Fri, Jan 09, 2009 at 11:33:04PM +0300, Anton Farygin wrote:
>> Kirill A. Shutemov пишет:
>>> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
>>>> ...
>>>>> Ну так что делать - udev действительно переодически (с новой версией)
>>>>> обрубает старые ядра... приходится мириться и жевать этот кактус.
>>>> udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
>>> Ну, тогда может стоит поставить там зависимость на версию kernel? Может
>>> энтропия снизится.
>> Это сложно. В системе может стоять несколько ядер, да и у нас не принято 
>> делать зависимость у userspace на kernel.
>>
>> будут проблемы при dist-upgrade - влетит первое попавшееся ядро (по 
>> алфавиту, если не ошибаюсь).
> 
> Сравнять в провах с модулями -- поставить на hold в дефолтном apt.conf.


         Allow-Duplicated {
                 // Old-style kernels.
 
"^(NVIDIA_)?(kernel|alsa)[0-9]*(-adv|-linus)?($|-up|-smp|-secure|-custom|-enterprise|-BOOT|-tape|-aureal)";
                 // New-style kernels.
              }

А чем поможет hold ?

Re: [devel] kernel requirement in userspace

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 23:46:17 09.01.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:
> 
>  DVL> По этой причине зависимость на ядро в userspace лишена смысла.
> 
> А конфликт со старыми ядрами? Впрочем, это опасно, если никто не требует
> "какого-нибудь" ядра :)

Не не не.. не надо конфликт. Если при обновлении вдруг будет вынесено 
старое ядро, с которым я как минимум могу загрузиться в некий single 
mode без udev, а новое ядро не заработает - то будет ай-яй-яй...

Кстати, нет ли возможность реализовать такую зависимость (точнее - 
алгоритм apt/rpm) на виртуальный пакет, когда будет устанавливаться 
новая версия реального пакета с именем, равным уже установленному 
старому пакету, имеющему такой же provides (kernel = x.y.z) как у нового 
пакета ?

Тогда обновление ядер будет работать, и зависимости можно смело делать.

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Led пишет:
> On Friday, 09 January 2009 22:34:37 Valery V. Inozemtsev wrote:
>> On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
>>> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
>>>> ...
>>>>
>>>>> Ну так что делать - udev действительно переодически (с новой версией)
>>>>> обрубает старые ядра... приходится мириться и жевать этот кактус.
>>>> udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
>>> Ну, тогда может стоит поставить там зависимость на версию kernel? Может
>>> энтропия снизится.
>> на какой kernel из?
> 
> На тот специальный Provides, который это ядро предоставит.

будет установлено произвольное ядро из Sisyphus, удовлетворяющее данному 
Provides.

Это мы уже проходили с ядерными модулями и fglrx/nvidia.

Re: [devel] udev

[Led]

On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote:
> On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote:
> [...]
>
> > А установить в систему пакет udev_X (где X - нужная версия) - вобще
> > невозможно. Потому, что:
> > $ grep udev /usr/lib/rpm/0common-files.req.list
> > /etc/udev/rules.d       udev-rules
> >
> > Это зачем? Что никому неповадно было нужный ему udev собрать?
>
> А чем 0common-files.req.list мешает кому-то собрать нужный ему udev?

Собрать - не мешает. Установить - раскажите как.
В 0common-files.req.list вобще костылей понатыкано - даже если хочется что-то 
исправить (некоторые пакеты) - не получится, без форканья rpm.
Вы тоже не можете объяснить, зачем эти костыли, если только не для того, чтобы 
совать палки в колёса мейнтейнерам?

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Friday, 09 January 2009 23:28:18 Anton Farygin wrote:
> Led пишет:
> > On Friday, 09 January 2009 22:34:37 Valery V. Inozemtsev wrote:
> >> On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
> >>> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
> >>>> ...
> >>>>
> >>>>> Ну так что делать - udev действительно переодически (с новой версией)
> >>>>> обрубает старые ядра... приходится мириться и жевать этот кактус.
> >>>>
> >>>> udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
> >>>
> >>> Ну, тогда может стоит поставить там зависимость на версию kernel? Может
> >>> энтропия снизится.
> >>
> >> на какой kernel из?
> >
> > На тот специальный Provides, который это ядро предоставит.
>
> будет установлено произвольное ядро из Sisyphus, удовлетворяющее данному
> Provides.
>
> Это мы уже проходили с ядерными модулями и fglrx/nvidia.

Это смотря какой именно Provides прописать в конкретном kernel-image.

-- 
Led

Re: [devel] udev

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

On Fri, Jan 09, 2009 at 11:40:11PM +0200, Led wrote:
> On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote:
> > On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote:
> > [...]
> >
> > > А установить в систему пакет udev_X (где X - нужная версия) - вобще
> > > невозможно. Потому, что:
> > > $ grep udev /usr/lib/rpm/0common-files.req.list
> > > /etc/udev/rules.d       udev-rules
> > >
> > > Это зачем? Что никому неповадно было нужный ему udev собрать?
> >
> > А чем 0common-files.req.list мешает кому-то собрать нужный ему udev?
> 
> Собрать - не мешает. Установить - раскажите как.

А в чём принципиальная сложность установить?

> В 0common-files.req.list вобще костылей понатыкано - даже если хочется что-то 
> исправить (некоторые пакеты) - не получится, без форканья rpm.
> Вы тоже не можете объяснить, зачем эти костыли, если только не для того, чтобы 
> совать палки в колёса мейнтейнерам?

Эта проактивная мера нужна для того, чтобы мантейнеры меньше ошибались.
Эдакий свод нежелательных ошибок.
Наш rpm-build содержит изрядное число подобных мер.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] udev

[Led]

On Friday, 09 January 2009 23:55:28 Dmitry V. Levin wrote:
> On Fri, Jan 09, 2009 at 11:40:11PM +0200, Led wrote:
> > On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote:
> > > On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote:
> > > [...]
> > >
> > > > А установить в систему пакет udev_X (где X - нужная версия) - вобще
> > > > невозможно. Потому, что:
> > > > $ grep udev /usr/lib/rpm/0common-files.req.list
> > > > /etc/udev/rules.d       udev-rules
> > > >
> > > > Это зачем? Что никому неповадно было нужный ему udev собрать?
> > >
> > > А чем 0common-files.req.list мешает кому-то собрать нужный ему udev?
> >
> > Собрать - не мешает. Установить - раскажите как.
>
> А в чём принципиальная сложность установить?

Странно слышать этот вопрос от разработчика ALT-RPM:)
Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на установку 
алтернативных пакетов (с другим именем, с версией в имени)? аргументов, кроме 
как "Для вашего же блага!" я не услышал.
Попробуйте установить альтернативную сборку udev_xyz, альтернативную сборку 
tetex (с tetex у меня в конце концов получилось, нагородив полдюжины 
костылей, чтобы обойти один костыль в rpm/0common-files.req.list) - не 
исключено, что у вас получится - возможно вы знаете "недокументированные 
возможности" или "секретные читы":)

Можно ещё вспомнить про "супероптимизированные зависимости" buildreq, когда на 
каждый чих приходится перегенировать BuildRequires и пересобирать сотню 
пакетов в репозитарии - просто удивительная "автоматизация" - помоб 
мейнтейнерам - ведь им от скуки и безделия просто девать себя нЕкуда:)

>
> > В 0common-files.req.list вобще костылей понатыкано - даже если хочется
> > что-то исправить (некоторые пакеты) - не получится, без форканья rpm.
> > Вы тоже не можете объяснить, зачем эти костыли, если только не для того,
> > чтобы совать палки в колёса мейнтейнерам?
>
> Эта проактивная мера нужна для того, чтобы мантейнеры меньше ошибались.
> Эдакий свод нежелательных ошибок.
> Наш rpm-build содержит изрядное число подобных мер.

Теперь понятно: чтоб не лезли, "куда не просят - будут меньше ошибаться":)

-- 
Led

Re: [devel] udev

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]


Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 >> А в чём принципиальная сложность установить?

 L> Странно слышать этот вопрос от разработчика ALT-RPM:)

 L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на
 L> установку алтернативных пакетов (с другим именем, с версией в
 L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал.

Предлагаю перейти к конструктиву: что конкретно ломается при установке
другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто
недопонимание или незадокументирование?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] udev

[Aleksey Novodvorsky]

10 января 2009 г. 1:58 пользователь Led <ledest@gmail.com> написал:
> On Friday, 09 January 2009 23:55:28 Dmitry V. Levin wrote:
>> On Fri, Jan 09, 2009 at 11:40:11PM +0200, Led wrote:
>> > On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote:
>> > > On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote:
>> > > [...]
>> > >
>> > > > А установить в систему пакет udev_X (где X - нужная версия) - вобще
>> > > > невозможно. Потому, что:
>> > > > $ grep udev /usr/lib/rpm/0common-files.req.list
>> > > > /etc/udev/rules.d       udev-rules
>> > > >
>> > > > Это зачем? Что никому неповадно было нужный ему udev собрать?
>> > >
>> > > А чем 0common-files.req.list мешает кому-то собрать нужный ему udev?
>> >
>> > Собрать - не мешает. Установить - раскажите как.
>>
>> А в чём принципиальная сложность установить?
>
> Странно слышать этот вопрос от разработчика ALT-RPM:)
> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на установку
> алтернативных пакетов (с другим именем, с версией в имени)? аргументов, кроме
> как "Для вашего же блага!" я не услышал.
> Попробуйте установить альтернативную сборку udev_xyz, альтернативную сборку
> tetex (с tetex у меня в конце концов получилось, нагородив полдюжины
> костылей, чтобы обойти один костыль в rpm/0common-files.req.list) - не
> исключено, что у вас получится - возможно вы знаете "недокументированные
> возможности" или "секретные читы":)
>
> Можно ещё вспомнить про "супероптимизированные зависимости" buildreq, когда на
> каждый чих приходится перегенировать BuildRequires и пересобирать сотню
> пакетов в репозитарии - просто удивительная "автоматизация" - помоб
> мейнтейнерам - ведь им от скуки и безделия просто девать себя нЕкуда:)

Пожалуй, это становится даже мне интересно. Все эти фичи появились
вчера?  Не лучше ли объяснить, что и как  Вам мешает, почему именно
сегодня и как по Вашему будет лучше _всем_ разработчикам?

Rgrds, Алексей

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 00:59:58 Mikhail Gusarov wrote:
> Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did gyre 
and gimble:
>  >> А в чём принципиальная сложность установить?
>
>  L> Странно слышать этот вопрос от разработчика ALT-RPM:)
>
>  L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на
>  L> установку алтернативных пакетов (с другим именем, с версией в
>  L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал.
>
> Предлагаю перейти к конструктиву: что конкретно ломается при установке
> другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто
> недопонимание или незадокументирование?

http://lists.altlinux.org/pipermail/devel/2008-July/157577.html

P.S.
"Proivdes: udev-rules" - не рашает, несмотря на утверждение at@

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Led пишет:
> On Friday, 09 January 2009 23:28:18 Anton Farygin wrote:
>> Led пишет:
>>> On Friday, 09 January 2009 22:34:37 Valery V. Inozemtsev wrote:
>>>> On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
>>>>> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
>>>>>> ...
>>>>>>
>>>>>>> Ну так что делать - udev действительно переодически (с новой версией)
>>>>>>> обрубает старые ядра... приходится мириться и жевать этот кактус.
>>>>>> udev это давно уже такая часть ядра. для старых ядер есть архив сизифа
>>>>> Ну, тогда может стоит поставить там зависимость на версию kernel? Может
>>>>> энтропия снизится.
>>>> на какой kernel из?
>>> На тот специальный Provides, который это ядро предоставит.
>> будет установлено произвольное ядро из Sisyphus, удовлетворяющее данному
>> Provides.
>>
>> Это мы уже проходили с ядерными модулями и fglrx/nvidia.
> 
> Это смотря какой именно Provides прописать в конкретном kernel-image.

Какой бы не прописал, всё равно будет плохо

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 01:13:35 Aleksey Novodvorsky wrote:
> 10 января 2009 г. 1:58 пользователь Led <ledest@gmail.com> написал:
> > On Friday, 09 January 2009 23:55:28 Dmitry V. Levin wrote:
> >> On Fri, Jan 09, 2009 at 11:40:11PM +0200, Led wrote:
> >> > On Friday, 09 January 2009 23:04:43 Dmitry V. Levin wrote:
> >> > > On Fri, Jan 09, 2009 at 10:50:44PM +0200, Led wrote:
> >> > > [...]
> >> > >
> >> > > > А установить в систему пакет udev_X (где X - нужная версия) -
> >> > > > вобще невозможно. Потому, что:
> >> > > > $ grep udev /usr/lib/rpm/0common-files.req.list
> >> > > > /etc/udev/rules.d       udev-rules
> >> > > >
> >> > > > Это зачем? Что никому неповадно было нужный ему udev собрать?
> >> > >
> >> > > А чем 0common-files.req.list мешает кому-то собрать нужный ему udev?
> >> >
> >> > Собрать - не мешает. Установить - раскажите как.
> >>
> >> А в чём принципиальная сложность установить?
> >
> > Странно слышать этот вопрос от разработчика ALT-RPM:)
> > Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на
> > установку алтернативных пакетов (с другим именем, с версией в имени)?
> > аргументов, кроме как "Для вашего же блага!" я не услышал.
> > Попробуйте установить альтернативную сборку udev_xyz, альтернативную
> > сборку tetex (с tetex у меня в конце концов получилось, нагородив
> > полдюжины костылей, чтобы обойти один костыль в
> > rpm/0common-files.req.list) - не исключено, что у вас получится -
> > возможно вы знаете "недокументированные возможности" или "секретные
> > читы":)
> >
> > Можно ещё вспомнить про "супероптимизированные зависимости" buildreq,
> > когда на каждый чих приходится перегенировать BuildRequires и
> > пересобирать сотню пакетов в репозитарии - просто удивительная
> > "автоматизация" - помоб мейнтейнерам - ведь им от скуки и безделия просто
> > девать себя нЕкуда:)
>
> Пожалуй, это становится даже мне интересно. Все эти фичи появились
> вчера?

Не вчера.

> Не лучше ли объяснить, что и как  Вам мешает,

Об этом был тред в devel@

> почему именно  
> сегодня и как по Вашему будет лучше _всем_ разработчикам?

Я задавал этот вопрос. получил ответ из разряда:
1) Так надо
2) Так красивее
3) Так на спек получается на 5 строчек короче

-- 
Led

Re: [devel] udev

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]


Twas brillig at 01:23:10 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 >> Предлагаю перейти к конструктиву: что конкретно ломается при
 >> установке другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь
 >> просто недопонимание или незадокументирование?

 L> http://lists.altlinux.org/pipermail/devel/2008-July/157577.html

 L> P.S.  "Proivdes: udev-rules" - не рашает, несмотря на утверждение
 L> at@

Так это ж баг, его надо повесить. Ответа в списке нету (есть только
последующий неконкретный стон в ltsp-server), бага в багзилле тоже не
видно - кто ж знал, что заявленная фича не работает, если про это никто
не сообщил?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Saturday, 10 January 2009 01:25:31 Anton Farygin wrote:
> Led пишет:
> > On Friday, 09 January 2009 23:28:18 Anton Farygin wrote:
> >> Led пишет:
> >>> On Friday, 09 January 2009 22:34:37 Valery V. Inozemtsev wrote:
> >>>> On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
> >>>>> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
> >>>>>> ...
> >>>>>>
> >>>>>>> Ну так что делать - udev действительно переодически (с новой
> >>>>>>> версией) обрубает старые ядра... приходится мириться и жевать этот
> >>>>>>> кактус.
> >>>>>>
> >>>>>> udev это давно уже такая часть ядра. для старых ядер есть архив
> >>>>>> сизифа
> >>>>>
> >>>>> Ну, тогда может стоит поставить там зависимость на версию kernel?
> >>>>> Может энтропия снизится.
> >>>>
> >>>> на какой kernel из?
> >>>
> >>> На тот специальный Provides, который это ядро предоставит.
> >>
> >> будет установлено произвольное ядро из Sisyphus, удовлетворяющее данному
> >> Provides.
> >>
> >> Это мы уже проходили с ядерными модулями и fglrx/nvidia.
> >
> > Это смотря какой именно Provides прописать в конкретном kernel-image.
>
> Какой бы не прописал, всё равно будет плохо

Возможно. Я не прорабатывал этот вопрос досконально и не тестировал варианты. 
С моей стороны это не было безоговорочным утверждением, а, скорее, 
полувопрос/полуидея. У меня нет экспериментальных данных, 100%-но 
подтверждающих, что это решаемо. Так же как и нет оснований утвеждать, что 
это нерешаемо и гарантированно в любом случае "будет плохо":)

-- 
Led

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 01:32:25 Mikhail Gusarov wrote:
> Twas brillig at 01:23:10 10.01.2009 UTC+02 when ledest@gmail.com did gyre 
and gimble:
>  >> Предлагаю перейти к конструктиву: что конкретно ломается при
>  >> установке другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь
>  >> просто недопонимание или незадокументирование?
>
>  L> http://lists.altlinux.org/pipermail/devel/2008-July/157577.html
>
>  L> P.S.  "Proivdes: udev-rules" - не рашает, несмотря на утверждение
>  L> at@
>
> Так это ж баг, его надо повесить. Ответа в списке нету (есть только
> последующий неконкретный стон в ltsp-server), бага в багзилле тоже не
> видно - кто ж знал, что заявленная фича не работает, если про это никто
> не сообщил?

Т.е. вы считаете, что это бага?
Мне показалось, что это, по всем признакам, "прибитая гвоздями" фича. Как я 
мог о фиче репортить в багзиллу?:)
Я сам мейнтейнер и знаю, что ничего неприятнее нет, как потратить пару дней на 
разборки с багрепортом, чтобы потом поставить на него статус NOTABUG:)

-- 
Led

Re: [devel] udev

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]


Twas brillig at 01:38:24 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> Т.е. вы считаете, что это бага?  Мне показалось, что это, по всем
 L> признакам, "прибитая гвоздями" фича. Как я мог о фиче репортить в
 L> багзиллу?:)

Бага. at говорит, что Provides решает, а на самом деле - не
решает. Налицо расходение между спецификацией (какая уж есть) и
реализацией.

 L> Я сам мейнтейнер и знаю, что ничего неприятнее нет, как потратить
 L> пару дней на разборки с багрепортом, чтобы потом поставить на него
 L> статус NOTABUG:)

Иногда это приятно - означает, что не придётся ещё месяц чинить, чтобы
потом поставить FIXED :)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On Sat, Jan 10, 2009 at 01:23:10AM +0200, Led wrote:
> On Saturday, 10 January 2009 00:59:58 Mikhail Gusarov wrote:
> > Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did gyre 
> and gimble:
> >  >> А в чём принципиальная сложность установить?
> >
> >  L> Странно слышать этот вопрос от разработчика ALT-RPM:)
> >
> >  L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на
> >  L> установку алтернативных пакетов (с другим именем, с версией в
> >  L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал.
> >
> > Предлагаю перейти к конструктиву: что конкретно ломается при установке
> > другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто
> > недопонимание или незадокументирование?
> 
> http://lists.altlinux.org/pipermail/devel/2008-July/157577.html
> 
> P.S.
> "Proivdes: udev-rules" - не рашает, несмотря на утверждение at@

По-настоящему будет плохо, если apt-get install /etc/udev/rules.d
не установит пакет udev-rules.

Между прочим, есть ли уверенность в том, что /etc/udev/rules.d/* из
пакетов будут нормально сосуществовать с достаточно старым udev'ом?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 01:39:26 Mikhail Gusarov wrote:
> Twas brillig at 01:38:24 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
>  L> Т.е. вы считаете, что это бага?  Мне показалось, что это, по всем
>  L> признакам, "прибитая гвоздями" фича. Как я мог о фиче репортить в
>  L> багзиллу?:)
>
> Бага. at говорит, что Provides решает, а на самом деле - не
> решает. Налицо расходение между спецификацией (какая уж есть) и
> реализацией.

Т.е. получается что механизм с костылём по имени 0common-files.req.list - одна 
сплошная бага? Спасибо, не прошло и двух лет и хоть кто-то из ALT это 
признал:)
Я не иронизирую (ну, почти:). Означает ли это, что отношение меняется 
с "отмахнулись - не до этого" на "некотарая заинтересовааность"? И можно 
поднимать другие вопросы, который в своё время "замяли"?

-- 
Led

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 01:47:41 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 01:23:10AM +0200, Led wrote:
> > On Saturday, 10 January 2009 00:59:58 Mikhail Gusarov wrote:
> > > Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did
> > > gyre
> >
> > and gimble:
> > >  >> А в чём принципиальная сложность установить?
> > >
> > >  L> Странно слышать этот вопрос от разработчика ALT-RPM:)
> > >
> > >  L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на
> > >  L> установку алтернативных пакетов (с другим именем, с версией в
> > >  L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал.
> > >
> > > Предлагаю перейти к конструктиву: что конкретно ломается при установке
> > > другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто
> > > недопонимание или незадокументирование?
> >
> > http://lists.altlinux.org/pipermail/devel/2008-July/157577.html
> >
> > P.S.
> > "Proivdes: udev-rules" - не рашает, несмотря на утверждение at@
>
> По-настоящему будет плохо, если apt-get install /etc/udev/rules.d
> не установит пакет udev-rules.
>
> Между прочим, есть ли уверенность в том, что /etc/udev/rules.d/* из
> пакетов будут нормально сосуществовать с достаточно старым udev'ом?

Нет, конечно. Для udev108 нужны udev108-rules.

-- 
Led

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 01:47:41 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 01:23:10AM +0200, Led wrote:
> > On Saturday, 10 January 2009 00:59:58 Mikhail Gusarov wrote:
> > > Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did
> > > gyre
> >
> > and gimble:
> > >  >> А в чём принципиальная сложность установить?
> > >
> > >  L> Странно слышать этот вопрос от разработчика ALT-RPM:)
> > >
> > >  L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на
> > >  L> установку алтернативных пакетов (с другим именем, с версией в
> > >  L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал.
> > >
> > > Предлагаю перейти к конструктиву: что конкретно ломается при установке
> > > другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто
> > > недопонимание или незадокументирование?
> >
> > http://lists.altlinux.org/pipermail/devel/2008-July/157577.html
> >
> > P.S.
> > "Proivdes: udev-rules" - не рашает, несмотря на утверждение at@
>
> По-настоящему будет плохо, если apt-get install /etc/udev/rules.d
> не установит пакет udev-rules.

Интересная конструкция. Вы уверены, что необходимость для пользователя в 
такой, ээээ, странной команде установки действительно существует?

-- 
Led

Re: [devel] udev

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]


Twas brillig at 01:49:35 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> Т.е. получается что механизм с костылём по имени
 L> 0common-files.req.list - одна сплошная бага?

Разумеется, нет. Багом является то, что sisyphus_check не проверяет
Provides.

Впрочем, в любом случае, костыли для объезда 0common-files.req.list не
нужны, нужно исправление бага в sisyphus_check. Который вы пока что не
повесили. Поскольку at в devel давно не видно - повесить будет не
вредно, чтобы не потерялось.

 L> Означает ли это, что отношение меняется с "отмахнулись - не до
 L> этого" на "некотарая заинтересовааность"?

Можно ли привести ссылки, подтверждающие в данном случае "отмахнулись"?
Последним письмом в вышеуказанном треде было письмо at@, описавшего
спецификацию механизма работы. Механизм не работает, но про это никаким
образом, кроме телепатического, догадаться было нельзя (опять же,
неконкретный стон в ltsp-server не считается).

 L> И можно поднимать другие вопросы, который в своё время "замяли"?

Замятые не по существу вопросы всегда можно и нужно поднимать, пока не
станет понятно, в чём вообще состоит проблема.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Anton Farygin]

Led пишет:
> On Saturday, 10 January 2009 01:47:41 Dmitry V. Levin wrote:
>> On Sat, Jan 10, 2009 at 01:23:10AM +0200, Led wrote:
>>> On Saturday, 10 January 2009 00:59:58 Mikhail Gusarov wrote:
>>>> Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did
>>>> gyre
>>> and gimble:
>>>>  >> А в чём принципиальная сложность установить?
>>>>
>>>>  L> Странно слышать этот вопрос от разработчика ALT-RPM:)
>>>>
>>>>  L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на
>>>>  L> установку алтернативных пакетов (с другим именем, с версией в
>>>>  L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал.
>>>>
>>>> Предлагаю перейти к конструктиву: что конкретно ломается при установке
>>>> другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто
>>>> недопонимание или незадокументирование?
>>> http://lists.altlinux.org/pipermail/devel/2008-July/157577.html
>>>
>>> P.S.
>>> "Proivdes: udev-rules" - не рашает, несмотря на утверждение at@
>> По-настоящему будет плохо, если apt-get install /etc/udev/rules.d
>> не установит пакет udev-rules.
> 
> Интересная конструкция. Вы уверены, что необходимость для пользователя в 
> такой, ээээ, странной команде установки действительно существует?
> 

Ответ на этот вопрос даст команда:

$ apt-cache whatdepends "/etc/udev/rules.d"

т.е. - пользователь напрямую apt-get install "/etc/udev/rules.d" не 
позовёт...

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Led пишет:
> On Saturday, 10 January 2009 01:25:31 Anton Farygin wrote:
>> Led пишет:
>>> On Friday, 09 January 2009 23:28:18 Anton Farygin wrote:
>>>> Led пишет:
>>>>> On Friday, 09 January 2009 22:34:37 Valery V. Inozemtsev wrote:
>>>>>> On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
>>>>>>> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev wrote:
>>>>>>>> ...
>>>>>>>>
>>>>>>>>> Ну так что делать - udev действительно переодически (с новой
>>>>>>>>> версией) обрубает старые ядра... приходится мириться и жевать этот
>>>>>>>>> кактус.
>>>>>>>> udev это давно уже такая часть ядра. для старых ядер есть архив
>>>>>>>> сизифа
>>>>>>> Ну, тогда может стоит поставить там зависимость на версию kernel?
>>>>>>> Может энтропия снизится.
>>>>>> на какой kernel из?
>>>>> На тот специальный Provides, который это ядро предоставит.
>>>> будет установлено произвольное ядро из Sisyphus, удовлетворяющее данному
>>>> Provides.
>>>>
>>>> Это мы уже проходили с ядерными модулями и fglrx/nvidia.
>>> Это смотря какой именно Provides прописать в конкретном kernel-image.
>> Какой бы не прописал, всё равно будет плохо
> 
> Возможно. Я не прорабатывал этот вопрос досконально и не тестировал варианты. 
> С моей стороны это не было безоговорочным утверждением, а, скорее, 
> полувопрос/полуидея. У меня нет экспериментальных данных, 100%-но 
> подтверждающих, что это решаемо. Так же как и нет оснований утвеждать, что 
> это нерешаемо и гарантированно в любом случае "будет плохо":)

Ну, я могу посоветовать убить какое-то время и поэкспериментировать, 
если моим словам доверия нет ;)

К тому-же, я не уверен что apt выполнит install а не update для нового 
ядра, если оно вытянется по зависимостям. Тут точно надо проверять.

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Twas brillig at 01:52:09 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 >> По-настоящему будет плохо, если apt-get install /etc/udev/rules.d не
 >> установит пакет udev-rules.

 L> Интересная конструкция. Вы уверены, что необходимость для
 L> пользователя в такой, ээээ, странной команде установки действительно
 L> существует?

Вероятно, можно считать что нет, если не окажется, что кто-нибудь из
хэшера/инасталлятора/прочих инструментов где-то внутри на это не
опирается.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]


Twas brillig at 02:15:44 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 >> Вероятно, можно считать что нет, если не окажется, что кто-нибудь из
 >> хэшера/инасталлятора/прочих инструментов где-то внутри на это не
 >> опирается.

 L> Может стОит "лечить" тех, кто опирается эти костыли,

Безусловно.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 02:05:30 Mikhail Gusarov wrote:
> Twas brillig at 01:52:09 10.01.2009 UTC+02 when ledest@gmail.com did gyre 
and gimble:
>  >> По-настоящему будет плохо, если apt-get install /etc/udev/rules.d не
>  >> установит пакет udev-rules.
>
>  L> Интересная конструкция. Вы уверены, что необходимость для
>  L> пользователя в такой, ээээ, странной команде установки действительно
>  L> существует?
>
> Вероятно, можно считать что нет, если не окажется, что кто-нибудь из
> хэшера/инасталлятора/прочих инструментов где-то внутри на это не
> опирается.

Может стОит "лечить" тех, кто опирается эти костыли, а не заставлять всех 
пользоваться этими и другими костылями, только для того, чтобы эти "больные" 
не чувствовали себя инвалидами?:)

P.S.
(На всякий случай) "лечить" и "больные" - это про пакеты, требующие костили в 
rpm для своего позорного существования, а не про людей:)

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Saturday, 10 January 2009 02:04:32 Anton Farygin wrote:
> Led пишет:
> > On Saturday, 10 January 2009 01:25:31 Anton Farygin wrote:
> >> Led пишет:
> >>> On Friday, 09 January 2009 23:28:18 Anton Farygin wrote:
> >>>> Led пишет:
> >>>>> On Friday, 09 January 2009 22:34:37 Valery V. Inozemtsev wrote:
> >>>>>> On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
> >>>>>>> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev 
wrote:
> >>>>>>>> ...
> >>>>>>>>
> >>>>>>>>> Ну так что делать - udev действительно переодически (с новой
> >>>>>>>>> версией) обрубает старые ядра... приходится мириться и жевать
> >>>>>>>>> этот кактус.
> >>>>>>>>
> >>>>>>>> udev это давно уже такая часть ядра. для старых ядер есть архив
> >>>>>>>> сизифа
> >>>>>>>
> >>>>>>> Ну, тогда может стоит поставить там зависимость на версию kernel?
> >>>>>>> Может энтропия снизится.
> >>>>>>
> >>>>>> на какой kernel из?
> >>>>>
> >>>>> На тот специальный Provides, который это ядро предоставит.
> >>>>
> >>>> будет установлено произвольное ядро из Sisyphus, удовлетворяющее
> >>>> данному Provides.
> >>>>
> >>>> Это мы уже проходили с ядерными модулями и fglrx/nvidia.
> >>>
> >>> Это смотря какой именно Provides прописать в конкретном kernel-image.
> >>
> >> Какой бы не прописал, всё равно будет плохо
> >
> > Возможно. Я не прорабатывал этот вопрос досконально и не тестировал
> > варианты. С моей стороны это не было безоговорочным утверждением, а,
> > скорее, полувопрос/полуидея. У меня нет экспериментальных данных, 100%-но
> > подтверждающих, что это решаемо. Так же как и нет оснований утвеждать,
> > что это нерешаемо и гарантированно в любом случае "будет плохо":)
>
> Ну, я могу посоветовать убить какое-то время и поэкспериментировать,
> если моим словам доверия нет ;)

У меня нет оснований недоверять тебе:) Но если бы ты привёл аргументы, на 
которых основывается твоё утверждение "в любом случае будет плохо" - сомнений 
практически не осталось бы:)

>
> К тому-же, я не уверен что apt выполнит install а не update для нового
> ядра, если оно вытянется по зависимостям. Тут точно надо проверять.

СтОит ли тратить врем на эти проверки? Если всё равно в репозитарии двух 
udev'ов разных версий существовать не может, а udev с версией в имени тоже не 
жылец?

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

Twas brillig at 02:20:05 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> Если всё равно в репозитарии двух udev'ов разных версий существовать
 L> не может, а udev с версией в имени тоже не жылец?

Я ничего не понимаю: в соседнем треде обсосали, что "не жилец" - это
баг. Я до сих пор не вижу повешанного бага с указанием на письмо at и
воспроизведением того, что версионированный udev с провайдом не проходит
sisyphus_check.

Вам-таки хочется пофрустрировать по поводу уродства репозитория и иметь
в дальнейшем возможность охать и ахать или решить проблему? Способ
решения кристально ясен.

Учтите, если дело не сдвинется с места, а эта тема всплывёт ещё раз - я
не дам вам разглагольствовать, что всё плохо, а буду тыкать в архив
списка рассылки.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 01:58:23 Mikhail Gusarov wrote:
> Twas brillig at 01:49:35 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
>  L> Т.е. получается что механизм с костылём по имени
>  L> 0common-files.req.list - одна сплошная бага?
>
> Разумеется, нет. Багом является то, что sisyphus_check не проверяет
> Provides.
>
> Впрочем, в любом случае, костыли для объезда 0common-files.req.list не
> нужны, нужно исправление бага в sisyphus_check. Который вы пока что не
> повесили.

А вот теперь вопрос: при чём тут sisyphus_check? Я в очередной раз повторяю: 
пакет СОБИРАЕТСЯ. Да, в хэшере. Да, с неотключенным sisyphus_check. Но в 
систему он если и устанавливается (?), то только "с бубном". И все "танцы с 
бубном" идут насмарку при первом же
apt-get dist-upgrade
(вопросительные знаки, потому что я не помню все детали, бинаного udev108 у 
меня уже нет, а собрать его из существующего udev108.spec не представляется 
возможным из-за "странностей" текущей klibc). А повторять всё "с нуля" чисто 
из академического интереса желания у меня нет, пока не будет хотя бы 90%-ной 
уверенности, что данный тред не закончится как и предидущие (т.е. ничем) :(

> Поскольку at в devel давно не видно - повесить будет не 
> вредно, чтобы не потерялось.
>
>  L> Означает ли это, что отношение меняется с "отмахнулись - не до
>  L> этого" на "некотарая заинтересовааность"?
>
> Можно ли привести ссылки, подтверждающие в данном случае "отмахнулись"?

Сорри, не коллекционирую:)

> Последним письмом в вышеуказанном треде было письмо at@, описавшего
> спецификацию механизма работы. Механизм не работает, но про это никаким
> образом, кроме телепатического, догадаться было нельзя (опять же,
> неконкретный стон в ltsp-server не считается).
>
>  L> И можно поднимать другие вопросы, который в своё время "замяли"?
>
> Замятые не по существу вопросы всегда можно и нужно поднимать, пока не
> станет понятно, в чём вообще состоит проблема.

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

-- 
Led

Re: [devel] udev

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]


Twas brillig at 02:23:59 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> А вот теперь вопрос: при чём тут sisyphus_check? Я в очередной раз
 L> повторяю: пакет СОБИРАЕТСЯ. Да, в хэшере. Да, с неотключенным
 L> sisyphus_check.

 L> Но в систему он если и устанавливается (?), то только "с бубном".

Отлично, тогда вообще письмо at@ было не в тему. Забыли про него.

 L> И все "танцы с бубном" идут насмарку при первом же apt-get
 L> dist-upgrade (вопросительные знаки, потому что я не помню все
 L> детали, бинаного udev108 у меня уже нет, а собрать его из
 L> существующего udev108.spec не представляется возможным из-за
 L> "странностей" текущей klibc).  А повторять всё "с нуля" чисто из
 L> академического интереса желания у меня нет, пока не будет хотя бы
 L> 90%-ной уверенности, что данный тред не закончится как и предидущие
 L> (т.е. ничем) :(

Если его закончить ничем, то он и закончится ничем. А если довести до
нормального багрепорта, то он не закончится ничем.

В том треде ничего не говорилось про то, что два udev'а не могут
сосуществовать. Если что-то глючит - надо воспроизвести и
отрепортить. Иначе оно так и будет кривым до скончания веков, создавая
поводы для брюзжания и мешая.

 >> Замятые не по существу вопросы всегда можно и нужно поднимать, пока не
 >> станет понятно, в чём вообще состоит проблема.

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

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 203 bytes --]

Twas brillig at 06:23:15 10.01.2009 UTC+06 when dottedmag@altlinux.org did gyre and gimble:

 MG> Я ничего не понимаю:

[]

discard it. см. соседнее письмо.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] udev

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

Twas brillig at 02:23:59 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

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

Значит, workaround'ы плодить и потом сопровождать их годами времени не
жаль? :)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Saturday, 10 January 2009 02:23:15 Mikhail Gusarov wrote:
> Twas brillig at 02:20:05 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
>  L> Если всё равно в репозитарии двух udev'ов разных версий существовать
>  L> не может, а udev с версией в имени тоже не жылец?
>
> Я ничего не понимаю: в соседнем треде обсосали, что "не жилец" - это
> баг. Я до сих пор не вижу повешанного бага с указанием на письмо at и
> воспроизведением того, что версионированный udev с провайдом не проходит
> sisyphus_check.

И не увидите. потому что sisyphus_check он проходит.

>
> Вам-таки хочется пофрустрировать по поводу уродства репозитория и иметь
> в дальнейшем возможность охать и ахать или решить проблему? Способ
> решения кристально ясен.
>
> Учтите, если дело не сдвинется с места,

Конечно "не сдвинется". До тех пор, пока вы не прекратите "перекладывать с 
больной головы на здоровую", а именно (в данном случае) баги rpm приписывать 
sisyphus_check. Только, пожалуйста, не надо мне приписывать, что я наезжал на 
sisyphus_check - я его вообще не упоминал, это вы его упомянули:)

> а эта тема всплывёт ещё раз - я 
> не дам вам разглагольствовать, что всё плохо, а буду тыкать в архив
> списка рассылки.

:)))

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Led пишет:
> On Saturday, 10 January 2009 02:04:32 Anton Farygin wrote:
>> Led пишет:
>>> On Saturday, 10 January 2009 01:25:31 Anton Farygin wrote:
>>>> Led пишет:
>>>>> On Friday, 09 January 2009 23:28:18 Anton Farygin wrote:
>>>>>> Led пишет:
>>>>>>> On Friday, 09 January 2009 22:34:37 Valery V. Inozemtsev wrote:
>>>>>>>> On Friday 09 January 2009 23:17:16 Kirill A. Shutemov wrote:
>>>>>>>>> On Fri, Jan 09, 2009 at 11:07:31PM +0300, Valery V. Inozemtsev 
> wrote:
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>>> Ну так что делать - udev действительно переодически (с новой
>>>>>>>>>>> версией) обрубает старые ядра... приходится мириться и жевать
>>>>>>>>>>> этот кактус.
>>>>>>>>>> udev это давно уже такая часть ядра. для старых ядер есть архив
>>>>>>>>>> сизифа
>>>>>>>>> Ну, тогда может стоит поставить там зависимость на версию kernel?
>>>>>>>>> Может энтропия снизится.
>>>>>>>> на какой kernel из?
>>>>>>> На тот специальный Provides, который это ядро предоставит.
>>>>>> будет установлено произвольное ядро из Sisyphus, удовлетворяющее
>>>>>> данному Provides.
>>>>>>
>>>>>> Это мы уже проходили с ядерными модулями и fglrx/nvidia.
>>>>> Это смотря какой именно Provides прописать в конкретном kernel-image.
>>>> Какой бы не прописал, всё равно будет плохо
>>> Возможно. Я не прорабатывал этот вопрос досконально и не тестировал
>>> варианты. С моей стороны это не было безоговорочным утверждением, а,
>>> скорее, полувопрос/полуидея. У меня нет экспериментальных данных, 100%-но
>>> подтверждающих, что это решаемо. Так же как и нет оснований утвеждать,
>>> что это нерешаемо и гарантированно в любом случае "будет плохо":)
>> Ну, я могу посоветовать убить какое-то время и поэкспериментировать,
>> если моим словам доверия нет ;)
> 
> У меня нет оснований недоверять тебе:) Но если бы ты привёл аргументы, на 
> которых основывается твоё утверждение "в любом случае будет плохо" - сомнений 
> практически не осталось бы:)

А разве и так не понятно ? Тогда может быть эту проблему прояснит немного:
$ apt-cache show kernel
Виртуальный пакет kernel предоставляется следующими пакетами:
   kernel-image-std-def#2.6.27-alt3 2.6.27-alt3
   kernel-image-std-def#2.6.27-alt5 2.6.27-alt5
   kernel-image-std-def#2.6.25-alt10 2.6.25-alt10
   kernel-image-std-def#2.6.25-alt9 2.6.25-alt9
   kernel-image-std-def#2.6.25-alt8 2.6.25-alt8
   kernel-image-std-srv#2.6.27-alt7 2.6.27-alt7
   kernel-image-std-pae#2.6.27-alt7 2.6.27-alt7
   kernel-image-std-ll#2.6.27-alt7 2.6.27-alt7
   kernel-image-std-def#2.6.27-alt7 2.6.27-alt7
   kernel-image-ovz-smp#2.6.26-alt0.3 2.6.26-alt0.3
   kernel-image-led-tc#2.6.22-alt23 2.6.22-alt23
You should explicitly select one to show.
E: Package kernel is a virtual package with multiple providers.

Т.е. - вытянется первый, по моему даже по алфавиту.. (т.е. - 
kernel-image-led-tc)

Хотя.. я нашёл один странный пакет, у которого прописана зависимость на 
kernel ;)
# apt-cache depends fvcool
fvcool-1.04-alt2
   Depends: <kernel>
     kernel-image-std-srv#2.6.27-alt7-2.6.27-alt7
     kernel-image-std-pae#2.6.27-alt7-2.6.27-alt7
     kernel-image-std-ll#2.6.27-alt7-2.6.27-alt7
     kernel-image-std-def#2.6.27-alt7-2.6.27-alt7
     kernel-image-std-def#2.6.27-alt5-2.6.27-alt5
     kernel-image-std-def#2.6.27-alt3-2.6.27-alt3
     kernel-image-std-def#2.6.25-alt10-2.6.25-alt10
     kernel-image-std-def#2.6.25-alt9-2.6.25-alt9
     kernel-image-std-def#2.6.25-alt8-2.6.25-alt8
     kernel-image-ovz-smp#2.6.26-alt0.3-2.6.26-alt0.3
     kernel-image-led-tc#2.6.22-alt23-2.6.22-alt23

будет установлен kernel-image-std-srv, если у него зависимость поправить 
как kernel >= 2.6.27 и в системе ядро 2.6.27 будет отсутствовать.

Эта "фича" - всегда работает с виртуальными пакетами...

Кстати, это наверняка обсуждалось в списках рассылки...

> 
>> К тому-же, я не уверен что apt выполнит install а не update для нового
>> ядра, если оно вытянется по зависимостям. Тут точно надо проверять.
> 
> СтОит ли тратить врем на эти проверки? Если всё равно в репозитарии двух 
> udev'ов разных версий существовать не может, а udev с версией в имени тоже не 
> жылец?

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

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

On Sat, Jan 10, 2009 at 01:50:37AM +0200, Led wrote:
> On Saturday, 10 January 2009 01:47:41 Dmitry V. Levin wrote:
> > On Sat, Jan 10, 2009 at 01:23:10AM +0200, Led wrote:
> > > On Saturday, 10 January 2009 00:59:58 Mikhail Gusarov wrote:
> > > > Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did
> > > > gyre
> > >
> > > and gimble:
> > > >  >> А в чём принципиальная сложность установить?
> > > >
> > > >  L> Странно слышать этот вопрос от разработчика ALT-RPM:)
> > > >
> > > >  L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на
> > > >  L> установку алтернативных пакетов (с другим именем, с версией в
> > > >  L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал.
> > > >
> > > > Предлагаю перейти к конструктиву: что конкретно ломается при установке
> > > > другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто
> > > > недопонимание или незадокументирование?
> > >
> > > http://lists.altlinux.org/pipermail/devel/2008-July/157577.html
> > >
> > > P.S.
> > > "Proivdes: udev-rules" - не рашает, несмотря на утверждение at@
> >
> > По-настоящему будет плохо, если apt-get install /etc/udev/rules.d
> > не установит пакет udev-rules.
> >
> > Между прочим, есть ли уверенность в том, что /etc/udev/rules.d/* из
> > пакетов будут нормально сосуществовать с достаточно старым udev'ом?
> 
> Нет, конечно. Для udev108 нужны udev108-rules.

Даже в моей небольшой системе
$ rpmquery -f /etc/udev/rules.d/* |sort -u |wc -l
5

Я про эти 4 пакета, есть ли уверенность в том, что они будут нормально
сосуществовать с достаточно старым udev108-rules?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 02:27:49 Mikhail Gusarov wrote:
> Twas brillig at 02:23:59 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
>  L> А вот теперь вопрос: при чём тут sisyphus_check? Я в очередной раз
>  L> повторяю: пакет СОБИРАЕТСЯ. Да, в хэшере. Да, с неотключенным
>  L> sisyphus_check.
>
>  L> Но в систему он если и устанавливается (?), то только "с бубном".
>
> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него.

Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо (ответ на 
пост @at) в рассылку. Естественно, там нет подробностей, 
разжёвывающих "почему так происходит" - at@ они не нужны были, он ведь в 
контексте того, что он делает:)

-- 
Led

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On Sat, Jan 10, 2009 at 03:02:31AM +0300, Anton Farygin wrote:
> Led пишет:
> >On Saturday, 10 January 2009 01:47:41 Dmitry V. Levin wrote:
[...]
> >>По-настоящему будет плохо, если apt-get install 
> >>/etc/udev/rules.d
> >>не установит пакет udev-rules.
> >
> >Интересная конструкция. Вы уверены, что 
> >необходимость для пользователя в такой, 
> >ээээ, странной команде установки 
> >действительно существует?
> 
> Ответ на этот вопрос даст команда:
> 
> $ apt-cache whatdepends "/etc/udev/rules.d"
> 
> т.е. - пользователь напрямую apt-get install 
> "/etc/udev/rules.d" не позовёт...

Антон, спасибо.
Вообще-то я думал, что задающему вопрос про udev-rules это очевидно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] udev

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]


Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него.

 L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо
 L> (ответ на пост @at) в рассылку. Естественно, там нет подробностей,
 L> разжёвывающих "почему так происходит" - at@ они не нужны были, он
 L> ведь в контексте того, что он делает:)

Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был про
sisyphus_check. В общем, осталось только разобраться, почему apt-у
плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто по
недоразумению, вопросов нет.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 02:29:05 Mikhail Gusarov wrote:
> Twas brillig at 02:23:59 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
>  L> Вот как раз с "всегда" и "нужно" - проблема (у меня). К сожалению, у
>  L> меня нет привычки и желания "зудеть и надоедать пока не обратят
>  L> внимания" - я жадный и мне жаль на это времени :(
>
> Значит, workaround'ы плодить и потом сопровождать их годами времени не
> жаль? :)

Вы знаете, а ведь так и есть: делать воркэраунды и пропатчить ядро, чтоб оно 
работало с новым udev в своё время оказалось в несколько раз проще и заняло 
на порядок меньше времени, чем попытки кого-то в чём-то убедить :(

-- 
Led

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 02:34:26 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 01:50:37AM +0200, Led wrote:
> > On Saturday, 10 January 2009 01:47:41 Dmitry V. Levin wrote:
> > > On Sat, Jan 10, 2009 at 01:23:10AM +0200, Led wrote:
> > > > On Saturday, 10 January 2009 00:59:58 Mikhail Gusarov wrote:
> > > > > Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com
> > > > > did gyre
> > > >
> > > > and gimble:
> > > > >  >> А в чём принципиальная сложность установить?
> > > > >
> > > > >  L> Странно слышать этот вопрос от разработчика ALT-RPM:)
> > > > >
> > > > >  L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение
> > > > > на L> установку алтернативных пакетов (с другим именем, с версией в
> > > > > L> имени)? аргументов, кроме как "Для вашего же блага!" я не
> > > > > услышал.
> > > > >
> > > > > Предлагаю перейти к конструктиву: что конкретно ломается при
> > > > > установке другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь
> > > > > просто недопонимание или незадокументирование?
> > > >
> > > > http://lists.altlinux.org/pipermail/devel/2008-July/157577.html
> > > >
> > > > P.S.
> > > > "Proivdes: udev-rules" - не рашает, несмотря на утверждение at@
> > >
> > > По-настоящему будет плохо, если apt-get install /etc/udev/rules.d
> > > не установит пакет udev-rules.
> > >
> > > Между прочим, есть ли уверенность в том, что /etc/udev/rules.d/* из
> > > пакетов будут нормально сосуществовать с достаточно старым udev'ом?
> >
> > Нет, конечно. Для udev108 нужны udev108-rules.
>
> Даже в моей небольшой системе
> $ rpmquery -f /etc/udev/rules.d/* |sort -u |wc -l
> 5
>
> Я про эти 4 пакета, есть ли уверенность в том, что они будут нормально
> сосуществовать с достаточно старым udev108-rules?

А разве не для этого существует
Requires: pkg >= x.y.z
?
Или требовать от пакета, чтобы он указывал, какая минимальная версия pkg ему 
требуется для работы (если "любая версия" ему не подходит) - это уже 
тоже "наезд"?:)

-- 
Led

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

On Sat, Jan 10, 2009 at 02:44:43AM +0200, Led wrote:
> On Saturday, 10 January 2009 02:34:26 Dmitry V. Levin wrote:
[...]
> > Даже в моей небольшой системе
> > $ rpmquery -f /etc/udev/rules.d/* |sort -u |wc -l
> > 5
> >
> > Я про эти 4 пакета, есть ли уверенность в том, что они будут нормально
> > сосуществовать с достаточно старым udev108-rules?
> 
> А разве не для этого существует
> Requires: pkg >= x.y.z
> ?
> Или требовать от пакета, чтобы он указывал, какая минимальная версия pkg ему 
> требуется для работы (если "любая версия" ему не подходит) - это уже 
> тоже "наезд"?:)

Обычно человек не знает, чему равно x.y.z; большинству мантейнеров проще
не поставить эту зависимость, чем узнавать, как она должна выглядеть,
ибо и без неё "всё работает".  Там, где нет автоматики (вроде зависимости
на soname или sh --rpm-requires), не стоит ждать от людей таких подвигов.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 02:37:28 Mikhail Gusarov wrote:
> Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did gyre 
and gimble:
>  >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него.
>
>  L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо
>  L> (ответ на пост @at) в рассылку. Естественно, там нет подробностей,
>  L> разжёвывающих "почему так происходит" - at@ они не нужны были, он
>  L> ведь в контексте того, что он делает:)
>
> Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был про
> sisyphus_check. В общем, осталось только разобраться, почему apt-у
> плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто по
> недоразумению, вопросов нет.

Да нет, конечно, вопросов:) Просто в этом треде возникло утверждение, 
что "udev сильно завязан на конкретную версию ядра" и 
предложение "привязывать" конкретные ядра с конкретными udev'ами.
На что я и заметил, что это врядли получится из-за прибитых гвоздями в rpm 
костылей.
Кстати, необходимость последних, кроме как "аргумента": "чтоб мейнтейнеры 
меньше ошибались", больше ничем не оправдывается?

-- 
Led

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]


Twas brillig at 03:50:11 10.01.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:

 DVL> Обычно человек не знает, чему равно x.y.z;

Насколько часто udev меняет несовместимым образом свои правила? Если
почти каждый релиз, то можно ставить зависимость автоматом при сборке
чего-то, имеющего /etc/udev/rules.d/* (максимум она промахнётся на
одну-две версии).

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

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] udev

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]


Twas brillig at 02:52:41 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> Кстати, необходимость последних, кроме как "аргумента": "чтоб
 L> мейнтейнеры меньше ошибались", больше ничем не оправдывается?

Пусть ответят прибивавшие. В архивах ничего не нашлось. У меня тоже
вопрос возник: почему проверки для мейнтейнеров находятся в rpm (или
apt? где оно там ломалось-то точно?), а не в sisyphus_check?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 02:50:11 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 02:44:43AM +0200, Led wrote:
> > On Saturday, 10 January 2009 02:34:26 Dmitry V. Levin wrote:
>
> [...]
>
> > > Даже в моей небольшой системе
> > > $ rpmquery -f /etc/udev/rules.d/* |sort -u |wc -l
> > > 5
> > >
> > > Я про эти 4 пакета, есть ли уверенность в том, что они будут нормально
> > > сосуществовать с достаточно старым udev108-rules?
> >
> > А разве не для этого существует
> > Requires: pkg >= x.y.z
> > ?
> > Или требовать от пакета, чтобы он указывал, какая минимальная версия pkg
> > ему требуется для работы (если "любая версия" ему не подходит) - это уже
> > тоже "наезд"?:)
>
> Обычно человек не знает, чему равно x.y.z; большинству мантейнеров проще
> не поставить эту зависимость, чем узнавать, как она должна выглядеть,
> ибо и без неё "всё работает".

Естественно! Но ведь существуют ещё и пользователи, умеющие пользоваться 
багзиллой, а в багзилле есть вариант "Severity: trivial"

> Там, где нет автоматики (вроде зависимости 
> на soname или sh --rpm-requires), не стоит ждать от людей таких подвигов.

Автоматические зависимости на soname или sh --rpm-requires - это здорово!
Но святая вера в непогрешимость автоматических зависимостей и в то, что кроме 
них больше ничего не нужно - это уже фанатизм, который не только вреден, но и 
опасен:)

-- 
Led

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 02:56:39 Mikhail Gusarov wrote:
> Twas brillig at 02:52:41 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
>  L> Кстати, необходимость последних, кроме как "аргумента": "чтоб
>  L> мейнтейнеры меньше ошибались", больше ничем не оправдывается?
>
> Пусть ответят прибивавшие. В архивах ничего не нашлось. У меня тоже
> вопрос возник: почему проверки для мейнтейнеров находятся в rpm (или
> apt? где оно там ломалось-то точно?), а не в sisyphus_check?

У меня есть подозрения, что подобные костыли появились во время 
очередного "аврала/дистрибутив нужен на вчера":) Но утверждать не стану - 
могу ошибаться.

-- 
Led

Re: [devel] udev

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

On Sat, Jan 10, 2009 at 02:52:41AM +0200, Led wrote:
> On Saturday, 10 January 2009 02:37:28 Mikhail Gusarov wrote:
> > Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did gyre 
> and gimble:
> >  >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него.
> >
> >  L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо
> >  L> (ответ на пост @at) в рассылку. Естественно, там нет подробностей,
> >  L> разжёвывающих "почему так происходит" - at@ они не нужны были, он
> >  L> ведь в контексте того, что он делает:)
> >
> > Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был про
> > sisyphus_check. В общем, осталось только разобраться, почему apt-у
> > плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто по
> > недоразумению, вопросов нет.
> 
> Да нет, конечно, вопросов:) Просто в этом треде возникло утверждение, 
> что "udev сильно завязан на конкретную версию ядра" и 
> предложение "привязывать" конкретные ядра с конкретными udev'ами.

Как вы это себе представляете в свете того, что содержимое
/etc/udev/rules.d/ размазано по пакетам?

> На что я и заметил, что это врядли получится из-за прибитых гвоздями в rpm 
> костылей.

Не надо называть удобный автогенератор зависимостей костылями.
Вас могут понять неправильно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] udev

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]


Twas brillig at 04:01:04 10.01.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:

 DVL> Как вы это себе представляете в свете того, что содержимое
 DVL> /etc/udev/rules.d/ размазано по пакетам?

В случае сильной необходимости можно и /etc/udev_nnn/* добавить, и
поручить его наполнять, опять же, мейнтейнеру udev_nnn, по результатам
жалоб пользователей.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

On Sat, Jan 10, 2009 at 02:57:26AM +0200, Led wrote:
> On Saturday, 10 January 2009 02:50:11 Dmitry V. Levin wrote:
> > On Sat, Jan 10, 2009 at 02:44:43AM +0200, Led wrote:
> > > On Saturday, 10 January 2009 02:34:26 Dmitry V. Levin wrote:
> >
> > [...]
> >
> > > > Даже в моей небольшой системе
> > > > $ rpmquery -f /etc/udev/rules.d/* |sort -u |wc -l
> > > > 5
> > > >
> > > > Я про эти 4 пакета, есть ли уверенность в том, что они будут нормально
> > > > сосуществовать с достаточно старым udev108-rules?
> > >
> > > А разве не для этого существует
> > > Requires: pkg >= x.y.z
> > > ?
> > > Или требовать от пакета, чтобы он указывал, какая минимальная версия pkg
> > > ему требуется для работы (если "любая версия" ему не подходит) - это уже
> > > тоже "наезд"?:)
> >
> > Обычно человек не знает, чему равно x.y.z; большинству мантейнеров проще
> > не поставить эту зависимость, чем узнавать, как она должна выглядеть,
> > ибо и без неё "всё работает".
> 
> Естественно! Но ведь существуют ещё и пользователи, умеющие пользоваться 
> багзиллой, а в багзилле есть вариант "Severity: trivial"

Факт существования таких пользователей не является очевидным, к сожалению.
Особенно при малой вероятности оказаться в этой ситуации.

> > Там, где нет автоматики (вроде зависимости 
> > на soname или sh --rpm-requires), не стоит ждать от людей таких подвигов.
> 
> Автоматические зависимости на soname или sh --rpm-requires - это здорово!
> Но святая вера в непогрешимость автоматических зависимостей и в то, что кроме 
> них больше ничего не нужно - это уже фанатизм, который не только вреден, но и 
> опасен:)

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 03:01:04 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 02:52:41AM +0200, Led wrote:
> > On Saturday, 10 January 2009 02:37:28 Mikhail Gusarov wrote:
> > > Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did
> > > gyre
> >
> > and gimble:
> > >  >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него.
> > >
> > >  L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо
> > >  L> (ответ на пост @at) в рассылку. Естественно, там нет подробностей,
> > >  L> разжёвывающих "почему так происходит" - at@ они не нужны были, он
> > >  L> ведь в контексте того, что он делает:)
> > >
> > > Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был
> > > про sisyphus_check. В общем, осталось только разобраться, почему apt-у
> > > плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто по
> > > недоразумению, вопросов нет.
> >
> > Да нет, конечно, вопросов:) Просто в этом треде возникло утверждение,
> > что "udev сильно завязан на конкретную версию ядра" и
> > предложение "привязывать" конкретные ядра с конкретными udev'ами.
>
> Как вы это себе представляете в свете того, что содержимое
> /etc/udev/rules.d/ размазано по пакетам?

Я себе представляю (и вы, наверное, тоже, хоть и не хотите в этом признаться), 
что вариант ставить зависимость на каталог, а не на пакет, безусловно имеет 
право на существование, но этот вариант не является "серебрянной пулей" и 
универсальным на ВСЕ случаи жизни:)

>
> > На что я и заметил, что это врядли получится из-за прибитых гвоздями в
> > rpm костылей.
>
> Не надо называть удобный автогенератор зависимостей костылями.
> Вас могут понять неправильно.

Почему же - поняли правильно. А вот реакция... в общем - не удивила:)

-- 
Led

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 03:08:01 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 02:57:26AM +0200, Led wrote:
> > On Saturday, 10 January 2009 02:50:11 Dmitry V. Levin wrote:
> > > On Sat, Jan 10, 2009 at 02:44:43AM +0200, Led wrote:
> > > > On Saturday, 10 January 2009 02:34:26 Dmitry V. Levin wrote:
> > >
> > > [...]
> > >
> > > > > Даже в моей небольшой системе
> > > > > $ rpmquery -f /etc/udev/rules.d/* |sort -u |wc -l
> > > > > 5
> > > > >
> > > > > Я про эти 4 пакета, есть ли уверенность в том, что они будут
> > > > > нормально сосуществовать с достаточно старым udev108-rules?
> > > >
> > > > А разве не для этого существует
> > > > Requires: pkg >= x.y.z
> > > > ?
> > > > Или требовать от пакета, чтобы он указывал, какая минимальная версия
> > > > pkg ему требуется для работы (если "любая версия" ему не подходит) -
> > > > это уже тоже "наезд"?:)
> > >
> > > Обычно человек не знает, чему равно x.y.z; большинству мантейнеров
> > > проще не поставить эту зависимость, чем узнавать, как она должна
> > > выглядеть, ибо и без неё "всё работает".
> >
> > Естественно! Но ведь существуют ещё и пользователи, умеющие пользоваться
> > багзиллой, а в багзилле есть вариант "Severity: trivial"
>
> Факт существования таких пользователей не является очевидным, к сожалению.
> Особенно при малой вероятности оказаться в этой ситуации.
>
> > > Там, где нет автоматики (вроде зависимости
> > > на soname или sh --rpm-requires), не стоит ждать от людей таких
> > > подвигов.
> >
> > Автоматические зависимости на soname или sh --rpm-requires - это здорово!
> > Но святая вера в непогрешимость автоматических зависимостей и в то, что
> > кроме них больше ничего не нужно - это уже фанатизм, который не только
> > вреден, но и опасен:)
>
> Поведение по умолчанию должно быть наиболее подходящим для усреднённого
> пользователя, который (в данном случае "обычный" мантейнер) достаточно
> ленив.  Ладно, это уже начинается трепология, закругляюсь.

Не совсем "трепология":) Просто очень мало абсолютно однозначных вещей в этом 
мире. А попытки подогнать под однозначность - это обман (возможно, в т.ч. и 
самообман).

-- 
Led

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Sat, Jan 10, 2009 at 03:12:19AM +0200, Led wrote:
> On Saturday, 10 January 2009 03:08:01 Dmitry V. Levin wrote:
[...]
> > Поведение по умолчанию должно быть наиболее подходящим для усреднённого
> > пользователя, который (в данном случае "обычный" мантейнер) достаточно
> > ленив.  Ладно, это уже начинается трепология, закругляюсь.
> 
> Не совсем "трепология":) Просто очень мало абсолютно однозначных вещей в этом 
> мире. А попытки подогнать под однозначность - это обман (возможно, в т.ч. и 
> самообман).

Считается, что сферический конь можно получить только в вакууме,
а в реальных условиях он недостижим.

Давайте решать задачи по мере их поступления.
Их уже и так поступило немало.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 03:09:04 Led wrote:
> On Saturday, 10 January 2009 03:01:04 Dmitry V. Levin wrote:
> > On Sat, Jan 10, 2009 at 02:52:41AM +0200, Led wrote:
> > > On Saturday, 10 January 2009 02:37:28 Mikhail Gusarov wrote:
> > > > Twas brillig at 02:34:37 10.01.2009 UTC+02 when ledest@gmail.com did
> > > > gyre
> > >
> > > and gimble:
> > > >  >> Отлично, тогда вообще письмо at@ было не в тему. Забыли про него.
> > > >
> > > >  L> Я вам не давал ссылку на "письмо at@". Я дал сслку на своё письмо
> > > >  L> (ответ на пост @at) в рассылку. Естественно, там нет
> > > > подробностей, L> разжёвывающих "почему так происходит" - at@ они не
> > > > нужны были, он L> ведь в контексте того, что он делает:)
> > > >
> > > > Да, правда. Похоже, подробностей как раз и не хватило - ответ-то был
> > > > про sisyphus_check. В общем, осталось только разобраться, почему
> > > > apt-у плохеет. Надеюсь, с тем, что тема заглохла в прошлый раз просто
> > > > по недоразумению, вопросов нет.
> > >
> > > Да нет, конечно, вопросов:) Просто в этом треде возникло утверждение,
> > > что "udev сильно завязан на конкретную версию ядра" и
> > > предложение "привязывать" конкретные ядра с конкретными udev'ами.
> >
> > Как вы это себе представляете в свете того, что содержимое
> > /etc/udev/rules.d/ размазано по пакетам?
>
> Я себе представляю (и вы, наверное, тоже, хоть и не хотите в этом
> признаться), что вариант ставить зависимость на каталог, а не на пакет,
> безусловно имеет право на существование, но этот вариант не является
> "серебрянной пулей" и универсальным на ВСЕ случаи жизни:)

Кстати, прошу прощения, если я туплю, но... а кому станет хуже, если
Provides: /etc/udev/rules.d/
будет в пакете udev rules, а не в 0common-files.req.list?

-- 
Led

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 03:14:23 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 03:12:19AM +0200, Led wrote:
> > On Saturday, 10 January 2009 03:08:01 Dmitry V. Levin wrote:
>
> [...]
>
> > > Поведение по умолчанию должно быть наиболее подходящим для усреднённого
> > > пользователя, который (в данном случае "обычный" мантейнер) достаточно
> > > ленив.  Ладно, это уже начинается трепология, закругляюсь.
> >
> > Не совсем "трепология":) Просто очень мало абсолютно однозначных вещей в
> > этом мире. А попытки подогнать под однозначность - это обман (возможно, в
> > т.ч. и самообман).
>
> Считается, что сферический конь можно получить только в вакууме,
> а в реальных условиях он недостижим.
>
> Давайте решать задачи по мере их поступления.

Этой фразой вы сами отвечаете на свои же вопросы или проиворечите сами себе:

----------------------------------------------------------------------------------------------------------------------
> Естественно! Но ведь существуют ещё и пользователи, умеющие пользоваться 
> багзиллой, а в багзилле есть вариант "Severity: trivial"

Факт существования таких пользователей не является очевидным, к сожалению.
Особенно при малой вероятности оказаться в этой ситуации.
---------------------------------------------------------------------------------------------------------------------

?:)

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On Sat, Jan 10, 2009 at 03:04:32AM +0300, Anton Farygin wrote:

AF> Ну, я могу посоветовать убить какое-то время и поэкспериментировать, 
AF> если моим словам доверия нет ;)
AF> К тому-же, я не уверен что apt выполнит install а не update для нового 
AF> ядра, если оно вытянется по зависимостям. Тут точно надо проверять.

А почему бы не ставить зависимость от ядра на udev? И не развести
несколько udev'ов в Сизифе с альтернативами, чтобы именно нужный udev
цеплялся при загрузке?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Sat, Jan 10, 2009 at 04:35:21AM +0300, Денис Смирнов wrote:
> On Sat, Jan 10, 2009 at 03:04:32AM +0300, Anton Farygin wrote:
> 
> AF> Ну, я могу посоветовать убить какое-то время и поэкспериментировать, 
> AF> если моим словам доверия нет ;)
> AF> К тому-же, я не уверен что apt выполнит install а не update для нового 
> AF> ядра, если оно вытянется по зависимостям. Тут точно надо проверять.
> 
> А почему бы не ставить зависимость от ядра на udev? И не развести
> несколько udev'ов в Сизифе с альтернативами, чтобы именно нужный udev
> цеплялся при загрузке?

Расплодив ядер, вы получите отрицательный результат.
Зачем совершать много неинтересной работы ради заведомо провального
результата?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Денис Смирнов пишет:
> On Sat, Jan 10, 2009 at 03:04:32AM +0300, Anton Farygin wrote:
> 
> AF> Ну, я могу посоветовать убить какое-то время и поэкспериментировать, 
> AF> если моим словам доверия нет ;)
> AF> К тому-же, я не уверен что apt выполнит install а не update для нового 
> AF> ядра, если оно вытянется по зависимостям. Тут точно надо проверять.
> 
> А почему бы не ставить зависимость от ядра на udev? И не развести
> несколько udev'ов в Сизифе с альтернативами, чтобы именно нужный udev
> цеплялся при загрузке?

Потому что ядер должно быть мало. У нас и так силы людей, собирающих 
ядра - ограничены. Их нужно концентрировать, а не распылять.

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

Re: [devel] /etc/udev/rules.d

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

On Sat, Jan 10, 2009 at 02:47:41AM +0300, Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 01:23:10AM +0200, Led wrote:
> > On Saturday, 10 January 2009 00:59:58 Mikhail Gusarov wrote:
> > > Twas brillig at 00:58:17 10.01.2009 UTC+02 when ledest@gmail.com did gyre 
> > and gimble:
> > >  >> А в чём принципиальная сложность установить?
> > >
> > >  L> Странно слышать этот вопрос от разработчика ALT-RPM:)
> > >
> > >  L> Это как раз я спрашивал: ЗАЧЕМ такое принципиальное ограничение на
> > >  L> установку алтернативных пакетов (с другим именем, с версией в
> > >  L> имени)? аргументов, кроме как "Для вашего же блага!" я не услышал.
> > >
> > > Предлагаю перейти к конструктиву: что конкретно ломается при установке
> > > другого udev_xyz и как это выглядит? Вдруг, мнэ, здесь просто
> > > недопонимание или незадокументирование?
> > 
> > http://lists.altlinux.org/pipermail/devel/2008-July/157577.html
> > 
> > P.S.
> > "Proivdes: udev-rules" - не рашает, несмотря на утверждение at@
> 
> По-настоящему будет плохо, если apt-get install /etc/udev/rules.d
> не установит пакет udev-rules.
> 
> Между прочим, есть ли уверенность в том, что /etc/udev/rules.d/* из
> пакетов будут нормально сосуществовать с достаточно старым udev'ом?

Вероятно, (не)совместимость тех или иных конструкций в правилах udev
с той или иной версией udev специфицирована, тогда проверка на совместимость
может быть формализована, а простановка нужной версии реализована 
в скриптах автоматической генерации зависимостей (files.req).

Проще говоря, если в пакете присутствует файл /etc/udev/rules.d/*, то при сборке
достаточно проанализировать его на предмет наличия неких "диагностических"
конструкций, чтобы вычислить правильный диапазон версий udev,
подходящих данному пакету. 

-- 
Kirill Maslinsky
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

On Sat, Jan 10, 2009 at 10:03:24AM +0300, Anton Farygin wrote:

AF> Потому что ядер должно быть мало. У нас и так силы людей, собирающих 
AF> ядра - ограничены. Их нужно концентрировать, а не распылять.

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

AF> Т.е. - на мой взгляд тезис - каждой кухарке по ядру - не верен в корне. 
AF> Лучше толпой исправлять одно ядро, чем одному человеку собирать пять 
AF> разных ядер.

Увы, не работает это.

Иногда нужно провести какие-то эксперименты, собрать "левое" ядро.
Или нужно ядро со специфическими патчами.
Или для специфических задач (как led-tc).

Так вот -- если люди не могут решать свои проблемы в рамках Сизифа, они
это будут делать в своих локальных репозиториях.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Sat, Jan 10, 2009 at 04:41:47AM +0300, Dmitry V. Levin wrote:

DVL> Расплодив ядер, вы получите отрицательный результат.
DVL> Зачем совершать много неинтересной работы ради заведомо провального
DVL> результата?

Это было разумно, когда ядра собирал kernel hacker, и любому было ясно что
все что будет собирать он сам для себя будет заведомо хуже.

Сейчас ситуация другая -- имеющиеся ядра устраивают не всех.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] /etc/udev/rules.d

[Dmitriy Khanzhin]

Kirill Maslinsky пишет:
> 
> Проще говоря, если в пакете присутствует файл /etc/udev/rules.d/*, то при сборке
> достаточно проанализировать его на предмет наличия неких "диагностических"
> конструкций, чтобы вычислить правильный диапазон версий udev,
> подходящих данному пакету. 
> 
Не факт. В пакете libgphoto2 правила генерятся динамически, и при сборке в /etc/udev/rules.d/
ложится пустой файл. Но мне тут сейчас достаточно автоматической зависимости на этот каталог.

-- 
Rgrds, jinn.

Re: [devel] /etc/udev/rules.d

[Kirill Maslinsky]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

On Sat, Jan 10, 2009 at 03:47:48PM +0300, Dmitriy Khanzhin wrote:
> Kirill Maslinsky пишет:
> >
> >Проще говоря, если в пакете присутствует 
> >файл /etc/udev/rules.d/*, то при сборке
> >достаточно проанализировать его на 
> >предмет наличия неких "диагностических"
> >конструкций, чтобы вычислить правильный 
> >диапазон версий udev,
> >подходящих данному пакету. 
> >
> Не факт. В пакете libgphoto2 правила генерятся 
> динамически, и при сборке в /etc/udev/rules.d/
> ложится пустой файл. Но мне тут сейчас 

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

> достаточно автоматической зависимости 
> на этот каталог.

Насколько я понял, в том и вопрос, как обеспечить возможность 
паковать разные версии udev параллельно, не усложнив жизнь 
мантейнерам пакетов с правилами udev.

-- 
Kirill Maslinsky
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] udev

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

* Led <ledest@> [090110 04:18]:
> Кстати, прошу прощения, если я туплю, но... а кому станет хуже, если
Хуже станет всем, кто кладёт что-то в /etc/udev/rules.d/.

> Provides: /etc/udev/rules.d/
> будет в пакете udev rules, а не в 0common-files.req.list?
А эта фраза вообще смысла не имеет.

В общем прежде чем критиковать (в очередной раз), было бы неплохо
побольше узнать о критикуемом предмете.  Кстати, об'яснение от
создателя этого механизма не так давно было в этой рассылке (или
я перепутал и это было в IRC).

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Sat, Jan 10, 2009 at 05:12:21PM +0300, Alexey I. Froloff wrote:
> * Led <ledest@> [090110 04:18]:
> > Кстати, прошу прощения, если я туплю, но... а кому станет хуже, если
> Хуже станет всем, кто кладёт что-то в /etc/udev/rules.d/.
> 
> > Provides: /etc/udev/rules.d/
> > будет в пакете udev rules, а не в 0common-files.req.list?
> А эта фраза вообще смысла не имеет.

Если я правильно понял спрашивающего, то он хотел узнать, что будет
плохого, если каталог /etc/udev/rules.d не будет закреплён за пакетом
udev-rules?  В этом случае ничто не остановит мантейнера пакета,
содержащего файл /etc/udev/rules.d/*, заодно запаковать и сам каталог
/etc/udev/rules.d

> В общем прежде чем критиковать (в очередной раз), было бы неплохо
> побольше узнать о критикуемом предмете.  Кстати, об'яснение от
> создателя этого механизма не так давно было в этой рассылке (или
> я перепутал и это было в IRC).

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


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] udev

[Led]

On Saturday, 10 January 2009 16:12:21 Alexey I. Froloff wrote:
> * Led <ledest@> [090110 04:18]:
> > Кстати, прошу прощения, если я туплю, но... а кому станет хуже, если
>
> Хуже станет всем, кто кладёт что-то в /etc/udev/rules.d/.
>
> > Provides: /etc/udev/rules.d/
> > будет в пакете udev rules, а не в 0common-files.req.list?
>
> А эта фраза вообще смысла не имеет.
>
> В общем прежде чем критиковать (в очередной раз), было бы неплохо
> побольше узнать о критикуемом предмете.

Я не критиковал, а просто спросил (нижайше попросив прощения, перед тем как 
спрашивать)! Сколько ещё раз нужно поприседать и сказать "Ку!" перед тем как 
что-то спросить?

> Кстати, об'яснение от 
> создателя этого механизма не так давно было в этой рассылке (или
> я перепутал и это было в IRC).

-- 
Led

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 16:31:20 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 05:12:21PM +0300, Alexey I. Froloff wrote:
> > * Led <ledest@> [090110 04:18]:
> > > Кстати, прошу прощения, если я туплю, но... а кому станет хуже, если
> >
> > Хуже станет всем, кто кладёт что-то в /etc/udev/rules.d/.
> >
> > > Provides: /etc/udev/rules.d/
> > > будет в пакете udev rules, а не в 0common-files.req.list?
> >
> > А эта фраза вообще смысла не имеет.
>
> Если я правильно понял спрашивающего, то он хотел узнать, что будет
> плохого, если каталог /etc/udev/rules.d не будет закреплён за пакетом
> udev-rules?  В этом случае ничто не остановит мантейнера пакета,
> содержащего файл /etc/udev/rules.d/*, заодно запаковать и сам каталог
> /etc/udev/rules.d

Проверка в sisyphus_check тоже "не остановит"?

>
> > В общем прежде чем критиковать (в очередной раз), было бы неплохо
> > побольше узнать о критикуемом предмете.  Кстати, об'яснение от
> > создателя этого механизма не так давно было в этой рассылке (или
> > я перепутал и это было в IRC).
>
> Я создал этот механизм, так что могу объяснить, если нужно.
> Только вы конкретнее спрашивайте, пожалуйста.

Ок, конкретизирую: если это для избежания ошибок ЗАПАКОВКИ, то почему этот 
механизм в rpm, а не в sisyphus_check?

-- 
Led

Re: [devel] [JT] Бага ( формально ) может и нет , а вот проблема есть!

[Michael Shigorin]

On Fri, Jan 09, 2009 at 07:39:59PM +0600, Alexey Morozov wrote:
> > При этом я понимаю, что удобнее баг видеть в багзилле, но его
> > отсутствие совсем НЕ ПОВОД от него отмахиваться, как будто
> > его не существует.
> Отсутствие бага в багзилле - это отсутствие повода _работать_
> по данной проблеме.

Не совсем: повод может быть другим, и обычно в таких случаях
он сводится или к договорным отношениям (когда багзилой может
быть и голова коллеги), или к дружеским персональным.

Только вот и тогда фиксировать в багзиле -- надёжней, особенно
если одним раундом подход к снаряду на практике не обойдётся.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

On Sat, Jan 10, 2009 at 04:39:20PM +0200, Led wrote:
> On Saturday, 10 January 2009 16:31:20 Dmitry V. Levin wrote:
> > On Sat, Jan 10, 2009 at 05:12:21PM +0300, Alexey I. Froloff wrote:
> > > * Led <ledest@> [090110 04:18]:
> > > > Кстати, прошу прощения, если я туплю, но... а кому станет хуже, если
> > >
> > > Хуже станет всем, кто кладёт что-то в /etc/udev/rules.d/.
> > >
> > > > Provides: /etc/udev/rules.d/
> > > > будет в пакете udev rules, а не в 0common-files.req.list?
> > >
> > > А эта фраза вообще смысла не имеет.
> >
> > Если я правильно понял спрашивающего, то он хотел узнать, что будет
> > плохого, если каталог /etc/udev/rules.d не будет закреплён за пакетом
> > udev-rules?  В этом случае ничто не остановит мантейнера пакета,
> > содержащего файл /etc/udev/rules.d/*, заодно запаковать и сам каталог
> > /etc/udev/rules.d
> 
> Проверка в sisyphus_check тоже "не остановит"?

Проверка в sisyphus_check (190-check-dirlist) непосредственно привязана к
/usr/lib/rpm/*-files.req.list: sisyphus_check считает нарушением только
такие запакованные каталоги, для которых в *-files.req.list указано имя
пакета-владельца.

> > > В общем прежде чем критиковать (в очередной раз), было бы неплохо
> > > побольше узнать о критикуемом предмете.  Кстати, об'яснение от
> > > создателя этого механизма не так давно было в этой рассылке (или
> > > я перепутал и это было в IRC).
> >
> > Я создал этот механизм, так что могу объяснить, если нужно.
> > Только вы конкретнее спрашивайте, пожалуйста.
> 
> Ок, конкретизирую: если это для избежания ошибок ЗАПАКОВКИ, то почему этот 
> механизм в rpm, а не в sisyphus_check?

Я думаю, для того, чтобы избежать дублирования.  
По существу привязка имени каталога к имени пакета используется только в
sisyphus_check, а rpm/files.req использует по существу только имя
каталога для порождения зависимости.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] /etc/udev/rules.d

[Michael Shigorin]

On Sat, Jan 10, 2009 at 01:52:09AM +0200, Led wrote:
> > > http://lists.altlinux.org/pipermail/devel/2008-July/157577.html
> > > "Proivdes: udev-rules" - не рашает, несмотря на утверждение at@
> > По-настоящему будет плохо, если apt-get install
> > /etc/udev/rules.d не установит пакет udev-rules.
> Интересная конструкция. Вы уверены, что необходимость для
> пользователя в такой, ээээ, странной команде установки
> действительно существует?

Насколько понимаю, речь об (авто)Requires:, а вовсе не
об установке руками.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] buildreq (was: udev)

[Michael Shigorin]

On Sat, Jan 10, 2009 at 02:13:35AM +0300, Aleksey Novodvorsky wrote:
> > Можно ещё вспомнить про "супероптимизированные зависимости"
> > buildreq, когда на каждый чих приходится перегенировать
> > BuildRequires и пересобирать сотню пакетов в репозитарии -
> > просто удивительная "автоматизация" - помоб мейнтейнерам -
> > ведь им от скуки и безделия просто девать себя нЕкуда:)
> Пожалуй, это становится даже мне интересно. Все эти фичи
> появились вчера?  Не лучше ли объяснить, что и как  Вам мешает,
> почему именно сегодня и как по Вашему будет лучше _всем_
> разработчикам?

Алексей, когда они появились -- я махал руками, подпрыгивал
и показывал пальцем на грабли.  Как обычно.

at@ это предупреждение из каких-то соображений в итоге
проигнорировал, ldv@ молча это подтвердил.

Через полтора года на граблях был устроен плац с libX*.
У меня на дурняк ушло два или три продуктивных дня.

http://lists.altlinux.org/pipermail/devel/2007-March/056364.html
http://lists.altlinux.org/pipermail/devel/2007-March/056371.html
http://lists.altlinux.org/pipermail/devel/2007-March/056388.html
http://lists.altlinux.org/pipermail/devel/2008-December/163888.html

PS: standalone buildreq2 использовал с 2005 или 2006 года.
Хорошая вещь, но buildreq, в противоположность мнению at@ --
ещё как ошибается: вместе с теми, кто ошибся в тарболе.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] /etc/udev/rules.d

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

* Led <ledest@> [090110 17:40]:
> Ок, конкретизирую: если это для избежания ошибок ЗАПАКОВКИ, то
> почему этот механизм в rpm, а не в sisyphus_check?
Загляни уже в этот "механизм в rpm".  Там Warning.  Чем он тебе
мешает?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 17:50:11 Alexey I. Froloff wrote:
> * Led <ledest@> [090110 17:40]:
> > Ок, конкретизирую: если это для избежания ошибок ЗАПАКОВКИ, то
> > почему этот механизм в rpm, а не в sisyphus_check?
>
> Загляни уже в этот "механизм в rpm".  Там Warning.  Чем он тебе
> мешает?

Да ничем. Я просто прикалываюсь.

-- 
Led

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]


Twas brillig at 17:59:40 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 >> Загляни уже в этот "механизм в rpm".  Там Warning.  Чем он тебе
 >> мешает?

 L> Да ничем. Я просто прикалываюсь.

А в чём проблема сделать два udev тогда?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Sat, Jan 10, 2009 at 10:00:48PM +0600, Mikhail Gusarov wrote:
> 
> Twas brillig at 17:59:40 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:
> 
>  >> Загляни уже в этот "механизм в rpm".  Там Warning.  Чем он тебе
>  >> мешает?
> 
>  L> Да ничем. Я просто прикалываюсь.
> 
> А в чём проблема сделать два udev тогда?

В том, что ему может потребоваться /etc/udev/rules.d с другим наполнением.

Представь себе PAM, которому нужен /etc/pam.d с немного другим
наполнением, и ты почувствуешь грандиозность изменений.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]


Twas brillig at 19:04:04 10.01.2009 UTC+03 when ldv@altlinux.org did gyre and gimble:

 >> А в чём проблема сделать два udev тогда?

 DVL> В том, что ему может потребоваться /etc/udev/rules.d с другим
 DVL> наполнением.

Я про принципиальные проблемы: sisyphus_check udev_nnn, по признанию
led'а, проходит, rpm выдаёт warning, а не ошибку, а /etc/udev/rules.d
можно и не читать, если уж приспичит, а самому таскать "в загашнике"
нужные версии, и это в любом дистрибутие так было бы.

Началось-то всё с того, что в такой-сякой нехорошей инфраструктуре всё
гвоздями прибито и обойти это нельзя. Так где гвозди-то?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Michael Shigorin]

On Sat, Jan 10, 2009 at 10:14:18PM +0600, Mikhail Gusarov wrote:
> Началось-то всё с того, что в такой-сякой нехорошей
> инфраструктуре всё гвоздями прибито и обойти это нельзя.
> Так где гвозди-то?

Ещё чуть раньше началось с того, что пересечение множеств
работоспособных версий ядер и udev в сизифе начало натирать
мозоли по крайней мере некоторым участникам team.

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 18:04:04 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 10:00:48PM +0600, Mikhail Gusarov wrote:
> > Twas brillig at 17:59:40 10.01.2009 UTC+02 when ledest@gmail.com did gyre 
and gimble:
> >  >> Загляни уже в этот "механизм в rpm".  Там Warning.  Чем он тебе
> >  >> мешает?
> >
> >  L> Да ничем. Я просто прикалываюсь.
> >
> > А в чём проблема сделать два udev тогда?
>
> В том, что ему может потребоваться /etc/udev/rules.d с другим наполнением.

До "наполнения" дело не доходит!
1) пакеты требуют /etc/udev/rules.d/
2) rpm сичтает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО udev-rules И 
НИКТО ДРУГОЙ

-- 
Led

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]


Twas brillig at 18:32:50 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> До "наполнения" дело не доходит!
 L> 1) пакеты требуют /etc/udev/rules.d/

 L> 2) rpm сичтает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО
 L> udev-rules И НИКТО ДРУГОЙ

Ура, наконец-то баг вскрылся. Всего-то полсотни писем пришлось написать :)

Значит udev-common и всё такое.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

On Sat, Jan 10, 2009 at 06:32:50PM +0200, Led wrote:
[...]
> 1) пакеты требуют /etc/udev/rules.d

И это правильно.  Никто не высказал сомнения в том, что это правильно.

> 2) rpm сичтает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО udev-rules И 
> НИКТО ДРУГОЙ

rpm только предупреждает, что.  А считает sisyphus_check.
Даже если бы sisyphus_check так не считал, я сомневаюсь в том, что
разные провайдеры /etc/udev/rules.d действительно могут одновременно
существовать в реальной жизни.

Зачем альтернативному udev'у /etc/udev/rules.d, если нет основания
полагаться на совместимость?
Он может использовать свой собственный rules.d.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] /etc/udev/rules.d

[Aleksey Novodvorsky]

10 января 2009 г. 19:38 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
>
> Twas brillig at 18:32:50 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:
>
>  L> До "наполнения" дело не доходит!
>  L> 1) пакеты требуют /etc/udev/rules.d/
>
>  L> 2) rpm сичтает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО
>  L> udev-rules И НИКТО ДРУГОЙ
>
> Ура, наконец-то баг вскрылся. Всего-то полсотни писем пришлось написать :)

Я пока не вижу бага, я вижу частную проблему, которая так и не описана
четко и полностью.
Хорошо бы сформулировать общую проблему, чтобы не делать "костыль" для
решения каждой частной.
Михаил (Гусаров), Вы можете это сделать?

Rgrds, Алексей

>
> Значит udev-common и всё такое.


>
> --
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 19:18:31 Dmitry V. Levin wrote:
> On Sat, Jan 10, 2009 at 06:32:50PM +0200, Led wrote:
> [...]
>
> > 1) пакеты требуют /etc/udev/rules.d
>
> И это правильно.  Никто не высказал сомнения в том, что это правильно.
>
> > 2) rpm сичтает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО
> > udev-rules И НИКТО ДРУГОЙ
>
> rpm только предупреждает, что.  А считает sisyphus_check.
> Даже если бы sisyphus_check так не считал, я сомневаюсь в том, что
> разные провайдеры /etc/udev/rules.d действительно могут одновременно
> существовать в реальной жизни.
>
> Зачем альтернативному udev'у /etc/udev/rules.d, если нет основания
> полагаться на совместимость?
> Он может использовать свой собственный rules.d.

1) ПАКЕТЫ требуют /etc/udev/rules.d/
2) rpm ПРИ УСТАНОВКЕ ПАКЕТА, ТРЕБУЩЕГО /etc/udev/rules.d/, считает, 
что /etc/udev/rules.d/ может предоставлять ТОЛЬКО udev-rules И НИКТО ДРУГОЙ

-- 
Led

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]


Twas brillig at 20:42:26 10.01.2009 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:

 AN> Я пока не вижу бага, я вижу частную проблему, которая так и не
 AN> описана четко и полностью.

 AN> Хорошо бы сформулировать общую проблему, чтобы не делать "костыль"
 AN> для решения каждой частной.

Совсем общая звучит как "надо больше общаться", если на то пошло. Менее
общая - неплохо бы изменения в таких вещах, как RPM, обсуждать *ДО* их
добавления (к дистрибутивостроителям это тоже относится, кстати).

В этом конкретном случае я так и не услышал ни одного объяснения, почему
такие странные и жёсткие проверки находятся в RPM, а не в
sisyphus_check.

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

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]


Twas brillig at 19:48:11 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> 2) rpm ПРИ УСТАНОВКЕ ПАКЕТА, ТРЕБУЩЕГО /etc/udev/rules.d/, считает,
 L> что /etc/udev/rules.d/ может предоставлять ТОЛЬКО udev-rules И НИКТО
 L> ДРУГОЙ

Так пусть ставит. Что он, мешает, что ли?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Anton Farygin]

Led пишет:
> On Saturday, 10 January 2009 19:18:31 Dmitry V. Levin wrote:
>> On Sat, Jan 10, 2009 at 06:32:50PM +0200, Led wrote:
>> [...]
>>
>>> 1) пакеты требуют /etc/udev/rules.d
>> И это правильно.  Никто не высказал сомнения в том, что это правильно.
>>
>>> 2) rpm сичтает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО
>>> udev-rules И НИКТО ДРУГОЙ
>> rpm только предупреждает, что.  А считает sisyphus_check.
>> Даже если бы sisyphus_check так не считал, я сомневаюсь в том, что
>> разные провайдеры /etc/udev/rules.d действительно могут одновременно
>> существовать в реальной жизни.
>>
>> Зачем альтернативному udev'у /etc/udev/rules.d, если нет основания
>> полагаться на совместимость?
>> Он может использовать свой собственный rules.d.
> 
> 1) ПАКЕТЫ требуют /etc/udev/rules.d/
> 2) rpm ПРИ УСТАНОВКЕ ПАКЕТА, ТРЕБУЩЕГО /etc/udev/rules.d/, считает, 
> что /etc/udev/rules.d/ может предоставлять ТОЛЬКО udev-rules И НИКТО ДРУГОЙ

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

Как обеспечить совместимость двух разных версий udev с правилами, 
хранящимися в сторонних пакетах ?

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 19:49:59 Mikhail Gusarov wrote:
> Twas brillig at 19:48:11 10.01.2009 UTC+02 when ledest@gmail.com did gyre
> and gimble:
>
>  L> 2) rpm ПРИ УСТАНОВКЕ ПАКЕТА, ТРЕБУЩЕГО /etc/udev/rules.d/, считает,
>  L> что /etc/udev/rules.d/ может предоставлять ТОЛЬКО udev-rules И НИКТО
>  L> ДРУГОЙ
>
> Так пусть ставит. Что он, мешает, что ли?

Да

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Денис Смирнов пишет:
> On Sat, Jan 10, 2009 at 04:41:47AM +0300, Dmitry V. Levin wrote:
> 
> DVL> Расплодив ядер, вы получите отрицательный результат.
> DVL> Зачем совершать много неинтересной работы ради заведомо провального
> DVL> результата?
> 
> Это было разумно, когда ядра собирал kernel hacker, и любому было ясно что
> все что будет собирать он сам для себя будет заведомо хуже.
> 
> Сейчас ситуация другая -- имеющиеся ядра устраивают не всех.

И кто мешает прислать патч мантейнеру ?

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]


Twas brillig at 19:54:25 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 >> Так пусть ставит. Что он, мешает, что ли?

 L> Да

Чем?

P.S: я начинаю понимать тех, кто "заминает" темы, которые вы
поднимаете. Мне уже интересно, как чем всё это закончится, а не было бы
так интересно - давно бы перестал тянуть клещами ответы.

Либо заканчивайте партизанить, либо заканчивайте ныть, что здесь всё
плохо.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Aleksey Novodvorsky]

10 января 2009 г. 20:49 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
>
> Twas brillig at 20:42:26 10.01.2009 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:
>
>  AN> Я пока не вижу бага, я вижу частную проблему, которая так и не
>  AN> описана четко и полностью.
>
>  AN> Хорошо бы сформулировать общую проблему, чтобы не делать "костыль"
>  AN> для решения каждой частной.
>
> Совсем общая звучит как "надо больше общаться", если на то пошло. Менее
> общая - неплохо бы изменения в таких вещах, как RPM, обсуждать *ДО* их
> добавления (к дистрибутивостроителям это тоже относится, кстати).

Почему так произошло -- другой вопрос.
Меня интересует общетехническая формулировка проблемы. Если бы на была
зафиксирована, то было бы легче.

Rgrds, Алексей

>
> В этом конкретном случае я так и не услышал ни одного объяснения, почему
> такие странные и жёсткие проверки находятся в RPM, а не в
> sisyphus_check.
>
> Впрочем, внутрь я не смотрел, так что не знаю, не ошибается ли здесь кто
> в своих доводах.
>
> --
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]


Twas brillig at 20:57:19 10.01.2009 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:

 AN> Почему так произошло -- другой вопрос.  Меня интересует
 AN> общетехническая формулировка проблемы. Если бы на была
 AN> зафиксирована, то было бы легче.

[по ответам led, не проверено] RPM не совсем обоснованно выдаёт
преференции определённым пакетам при установке, судя по всему - при
выборе из кандидатов.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Денис Смирнов пишет:
> On Sat, Jan 10, 2009 at 10:03:24AM +0300, Anton Farygin wrote:
> 
> AF> Потому что ядер должно быть мало. У нас и так силы людей, собирающих 
> AF> ядра - ограничены. Их нужно концентрировать, а не распылять.
> 
> До недавнего времени их было куда больше. И то, почему остался только один
> -- это хороший вопрос.

Поддержка ядра - это процедура, требующая доволно приличного времени и 
сил, не говоря уже про голову и руки.

То, что не все выдерживают - это нормальное явление.

> 
> AF> Т.е. - на мой взгляд тезис - каждой кухарке по ядру - не верен в корне. 
> AF> Лучше толпой исправлять одно ядро, чем одному человеку собирать пять 
> AF> разных ядер.
> 
> Увы, не работает это.
> 
> Иногда нужно провести какие-то эксперименты, собрать "левое" ядро.
> Или нужно ядро со специфическими патчами.
> Или для специфических задач (как led-tc).
> 
> Так вот -- если люди не могут решать свои проблемы в рамках Сизифа, они
> это будут делать в своих локальных репозиториях.

Думаю, что led-tc возможно перетащить на 2.6.27, с 2.6.22.. просто у 
Led'а на это в данный момент нет времени. Отсюда и грабли.

Я честно - не смотрел какой там функционал, но не понимаю, почему его 
нельзя реализовать в std-def.

Согласен, что бывают совсем странные случаи, когда лучше собрать ядро 
рядом (сам так делал). Но в идеале надо всё равно всё это хозяйство 
интегрировать в std-xxx (что и было сделано с v4l в своё время).

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 19:52:52 Anton Farygin wrote:
> Led пишет:
> > On Saturday, 10 January 2009 19:18:31 Dmitry V. Levin wrote:
> >> On Sat, Jan 10, 2009 at 06:32:50PM +0200, Led wrote:
> >> [...]
> >>
> >>> 1) пакеты требуют /etc/udev/rules.d
> >>
> >> И это правильно.  Никто не высказал сомнения в том, что это правильно.
> >>
> >>> 2) rpm сичтает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО
> >>> udev-rules И НИКТО ДРУГОЙ
> >>
> >> rpm только предупреждает, что.  А считает sisyphus_check.
> >> Даже если бы sisyphus_check так не считал, я сомневаюсь в том, что
> >> разные провайдеры /etc/udev/rules.d действительно могут одновременно
> >> существовать в реальной жизни.
> >>
> >> Зачем альтернативному udev'у /etc/udev/rules.d, если нет основания
> >> полагаться на совместимость?
> >> Он может использовать свой собственный rules.d.
> >
> > 1) ПАКЕТЫ требуют /etc/udev/rules.d/
> > 2) rpm ПРИ УСТАНОВКЕ ПАКЕТА, ТРЕБУЩЕГО /etc/udev/rules.d/, считает,
> > что /etc/udev/rules.d/ может предоставлять ТОЛЬКО udev-rules И НИКТО
> > ДРУГОЙ
>
> И это правильно. синтаксис рулезов может, меняется и будет меняться..
>
> Как обеспечить совместимость двух разных версий udev с правилами,
> хранящимися в сторонних пакетах ?

Я уже отвечал на этот вопрос.

-- 
Led

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]


Twas brillig at 20:01:14 10.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 >>  >> Так пусть ставит. Что он, мешает, что ли?
 >>  L> Да
 >> Чем?

 L> Ок, заканчиваю.

Вы не ответили на вопрос.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 19:56:30 Mikhail Gusarov wrote:
> Twas brillig at 19:54:25 10.01.2009 UTC+02 when ledest@gmail.com did gyre 
and gimble:
>  >> Так пусть ставит. Что он, мешает, что ли?
>
>  L> Да
>
> Чем?
>
> P.S: я начинаю понимать тех, кто "заминает" темы, которые вы
> поднимаете. Мне уже интересно, как чем всё это закончится, а не было бы
> так интересно - давно бы перестал тянуть клещами ответы.
>
> Либо заканчивайте партизанить, либо заканчивайте ныть, что здесь всё
> плохо.

Ок, заканчиваю.

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michael Shigorin]

On Sat, Jan 10, 2009 at 08:59:18PM +0300, Anton Farygin wrote:
> Я честно - не смотрел какой там функционал, но не понимаю,
> почему его нельзя реализовать в std-def.

compcache и ещё один патчик; обоим IMHO место в ванилле вообще,
но не уверен, что одно лишь их добавление в std-def будет
оптимально.  По крайней мере не факт, что результат опять влезет
в 16M RAM тонкого клиента.

> Согласен, что бывают совсем странные случаи, когда лучше
> собрать ядро рядом (сам так делал). Но в идеале надо всё равно
> всё это хозяйство интегрировать в std-xxx (что и было сделано
> с v4l в своё время).

Угу.

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Saturday, 10 January 2009 19:59:18 Anton Farygin wrote:
> Денис Смирнов пишет:
> > On Sat, Jan 10, 2009 at 10:03:24AM +0300, Anton Farygin wrote:
> >
> > AF> Потому что ядер должно быть мало. У нас и так силы людей, собирающих
> > AF> ядра - ограничены. Их нужно концентрировать, а не распылять.
> >
> > До недавнего времени их было куда больше. И то, почему остался только
> > один -- это хороший вопрос.
>
> Поддержка ядра - это процедура, требующая доволно приличного времени и
> сил, не говоря уже про голову и руки.
>
> То, что не все выдерживают - это нормальное явление.
>
> > AF> Т.е. - на мой взгляд тезис - каждой кухарке по ядру - не верен в
> > корне. AF> Лучше толпой исправлять одно ядро, чем одному человеку
> > собирать пять AF> разных ядер.
> >
> > Увы, не работает это.
> >
> > Иногда нужно провести какие-то эксперименты, собрать "левое" ядро.
> > Или нужно ядро со специфическими патчами.
> > Или для специфических задач (как led-tc).
> >
> > Так вот -- если люди не могут решать свои проблемы в рамках Сизифа, они
> > это будут делать в своих локальных репозиториях.
>
> Думаю, что led-tc возможно перетащить на 2.6.27, с 2.6.22..

Зачем? Чтоб было чем занаться ближайшие полгода тестируе его?

> просто у 
> Led'а на это в данный момент нет времени.

...И желания (см. выше)

> Отсюда и грабли. 
>
> Я честно - не смотрел какой там функционал, но не понимаю, почему его
> нельзя реализовать в std-def.

Наверное, потому что и тот, кто мейнтейнит std-def тоже не имеет никакого 
желания смотреть "какой там функционал".

>
> Согласен, что бывают совсем странные случаи, когда лучше собрать ядро
> рядом (сам так делал). Но в идеале надо всё равно всё это хозяйство
> интегрировать в std-xxx (что и было сделано с v4l в своё время).
Это работа (интеграция v4l) на пару часов.

-- 
Led

Re: [devel] /etc/udev/rules.d

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

* Mikhail Gusarov <dottedmag@> [090110 20:54]:
> В этом конкретном случае я так и не услышал ни одного объяснения, почему
> такие странные и жёсткие проверки находятся в RPM, а не в
> sisyphus_check.
Да нет никаких жёстких проверок в rpm!  Там Warning!!!

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 19:59:00 Mikhail Gusarov wrote:
> Twas brillig at 20:57:19 10.01.2009 UTC+03 when a.e.nvdv@gmail.com did gyre
> and gimble:
>
>  AN> Почему так произошло -- другой вопрос.  Меня интересует
>  AN> общетехническая формулировка проблемы. Если бы на была
>  AN> зафиксирована, то было бы легче.
>
> [по ответам led, не проверено]

[не опровергнуто]

> RPM не совсем обоснованно выдаёт 
> преференции определённым пакетам при установке, судя по всему - при
> выборе из кандидатов.

Нет никакого выбора из кандидатов. Он требует ТОЛЬКО udev-rules - никакие 
другие варианты даже не рассматриваются.

-- 
Led

Re: [devel] /etc/udev/rules.d

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]


Twas brillig at 21:09:46 10.01.2009 UTC+03 when raorn@altlinux.ru did gyre and gimble:

 >> В этом конкретном случае я так и не услышал ни одного объяснения,
 >> почему такие странные и жёсткие проверки находятся в RPM, а не в
 >> sisyphus_check.

 AIF> Да нет никаких жёстких проверок в rpm!  Там Warning!!!

Гм. Значит мне led голову морочит уже со вчера?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

* Led <ledest@> [090110 20:54]:
> 2) rpm ПРИ УСТАНОВКЕ ПАКЕТА, ТРЕБУЩЕГО /etc/udev/rules.d/,
> считает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО
> udev-rules И НИКТО ДРУГОЙ
Опять Вы врёте, Новосельцев.  rpm такой ерунды не считает, он
считать не обучен.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 20:12:33 Mikhail Gusarov wrote:
> Twas brillig at 21:09:46 10.01.2009 UTC+03 when raorn@altlinux.ru did gyre 
and gimble:
>  >> В этом конкретном случае я так и не услышал ни одного объяснения,
>  >> почему такие странные и жёсткие проверки находятся в RPM, а не в
>  >> sisyphus_check.
>
>  AIF> Да нет никаких жёстких проверок в rpm!  Там Warning!!!
>
> Гм. Значит мне led голову морочит уже со вчера?

Warning при УСТАНОВКЕ пакета?:)

-- 
Led

Re: [devel] /etc/udev/rules.d

[Anton Farygin]

Led пишет:
> On Saturday, 10 January 2009 19:52:52 Anton Farygin wrote:
>> Led пишет:
>>> On Saturday, 10 January 2009 19:18:31 Dmitry V. Levin wrote:
>>>> On Sat, Jan 10, 2009 at 06:32:50PM +0200, Led wrote:
>>>> [...]
>>>>
>>>>> 1) пакеты требуют /etc/udev/rules.d
>>>> И это правильно.  Никто не высказал сомнения в том, что это правильно.
>>>>
>>>>> 2) rpm сичтает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО
>>>>> udev-rules И НИКТО ДРУГОЙ
>>>> rpm только предупреждает, что.  А считает sisyphus_check.
>>>> Даже если бы sisyphus_check так не считал, я сомневаюсь в том, что
>>>> разные провайдеры /etc/udev/rules.d действительно могут одновременно
>>>> существовать в реальной жизни.
>>>>
>>>> Зачем альтернативному udev'у /etc/udev/rules.d, если нет основания
>>>> полагаться на совместимость?
>>>> Он может использовать свой собственный rules.d.
>>> 1) ПАКЕТЫ требуют /etc/udev/rules.d/
>>> 2) rpm ПРИ УСТАНОВКЕ ПАКЕТА, ТРЕБУЩЕГО /etc/udev/rules.d/, считает,
>>> что /etc/udev/rules.d/ может предоставлять ТОЛЬКО udev-rules И НИКТО
>>> ДРУГОЙ
>> И это правильно. синтаксис рулезов может, меняется и будет меняться..
>>
>> Как обеспечить совместимость двух разных версий udev с правилами,
>> хранящимися в сторонних пакетах ?
> 
> Я уже отвечал на этот вопрос.
> 

Я, честно говоря, не помню ответа :( В треде не нашёл.

Re: [devel] /etc/udev/rules.d

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 138 bytes --]

* Mikhail Gusarov <dottedmag@> [090110 21:17]:
> Гм. Значит мне led голову морочит уже со вчера?
Конечно.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 20:13:15 Alexey I. Froloff wrote:
> * Led <ledest@> [090110 20:54]:
> > 2) rpm ПРИ УСТАНОВКЕ ПАКЕТА, ТРЕБУЩЕГО /etc/udev/rules.d/,
> > считает, что /etc/udev/rules.d/ может предоставлять ТОЛЬКО
> > udev-rules И НИКТО ДРУГОЙ
>
> Опять Вы врёте, Новосельцев.  rpm такой ерунды не считает, он
> считать не обучен.

Я вас прекрасно понимаю. Если бы мне такое про rpm сказали - я бы рассмеялся в 
лицо, потому что "обучать ЭТОМУ" rpm - как минимум смешно.

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Michael Shigorin пишет:
> On Sat, Jan 10, 2009 at 08:59:18PM +0300, Anton Farygin wrote:
>> Я честно - не смотрел какой там функционал, но не понимаю,
>> почему его нельзя реализовать в std-def.
> 
> compcache и ещё один патчик; обоим IMHO место в ванилле вообще,
> но не уверен, что одно лишь их добавление в std-def будет
> оптимально.  По крайней мере не факт, что результат опять влезет
> в 16M RAM тонкого клиента.

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

> 
>> Согласен, что бывают совсем странные случаи, когда лучше
>> собрать ядро рядом (сам так делал). Но в идеале надо всё равно
>> всё это хозяйство интегрировать в std-xxx (что и было сделано
>> с v4l в своё время).
> 
> Угу.
> 
> Бишь лучше по возможности сводить ядра, чтоб меньше лопатить
> по углам одно и то же.

О чём и речь.

Re: [devel] /etc/udev/rules.d

[Aleksey Novodvorsky]

10 января 2009 г. 21:11 пользователь Led <ledest@gmail.com> написал:
> On Saturday, 10 January 2009 19:59:00 Mikhail Gusarov wrote:
>> Twas brillig at 20:57:19 10.01.2009 UTC+03 when a.e.nvdv@gmail.com did gyre
>> and gimble:
>>
>>  AN> Почему так произошло -- другой вопрос.  Меня интересует
>>  AN> общетехническая формулировка проблемы. Если бы на была
>>  AN> зафиксирована, то было бы легче.
>>
>> [по ответам led, не проверено]
>
> [не опровергнуто]
>
>> RPM не совсем обоснованно выдаёт
>> преференции определённым пакетам при установке, судя по всему - при
>> выборе из кандидатов.
>
> Нет никакого выбора из кандидатов. Он требует ТОЛЬКО udev-rules - никакие
> другие варианты даже не рассматриваются.

Вам нужно сосуществование двух udev* в системе для ядер разных версий
или взаимозаменяемость?

Rgrds, Алексей

Re: [devel] /etc/udev/rules.d

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

* Led <ledest@> [090110 21:17]:
> Нет никакого выбора из кандидатов. Он требует ТОЛЬКО udev-rules - никакие 
> другие варианты даже не рассматриваются.
И опять неправда.

$ apt-cache showpkg udev-rules | grep '^  '
  udev-initramfs,udev-rules 135-alt2
  udev,udev-rules 135-alt2
  zaptel,udev-rules
  udev-initramfs,udev-rules 136-alt1
  udev,udev-rules 136-alt1
  bluez-utils,udev-rules 124-alt2

Все эти зависимости на udev-rules вписаны руками.  Сравните с

$ apt-cache showpkg /etc/udev/rules.d | grep '^  ' | wc -l
35

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Led пишет:
> On Saturday, 10 January 2009 19:59:18 Anton Farygin wrote:
>> Денис Смирнов пишет:
>>> On Sat, Jan 10, 2009 at 10:03:24AM +0300, Anton Farygin wrote:
>>>
>>> AF> Потому что ядер должно быть мало. У нас и так силы людей, собирающих
>>> AF> ядра - ограничены. Их нужно концентрировать, а не распылять.
>>>
>>> До недавнего времени их было куда больше. И то, почему остался только
>>> один -- это хороший вопрос.
>> Поддержка ядра - это процедура, требующая доволно приличного времени и
>> сил, не говоря уже про голову и руки.
>>
>> То, что не все выдерживают - это нормальное явление.
>>
>>> AF> Т.е. - на мой взгляд тезис - каждой кухарке по ядру - не верен в
>>> корне. AF> Лучше толпой исправлять одно ядро, чем одному человеку
>>> собирать пять AF> разных ядер.
>>>
>>> Увы, не работает это.
>>>
>>> Иногда нужно провести какие-то эксперименты, собрать "левое" ядро.
>>> Или нужно ядро со специфическими патчами.
>>> Или для специфических задач (как led-tc).
>>>
>>> Так вот -- если люди не могут решать свои проблемы в рамках Сизифа, они
>>> это будут делать в своих локальных репозиториях.
>> Думаю, что led-tc возможно перетащить на 2.6.27, с 2.6.22..
> 
> Зачем? Чтоб было чем занаться ближайшие полгода тестируе его?

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

> 
>> просто у 
>> Led'а на это в данный момент нет времени.
> 
> ...И желания (см. выше)
> 
>> Отсюда и грабли. 
>>
>> Я честно - не смотрел какой там функционал, но не понимаю, почему его
>> нельзя реализовать в std-def.
> 
> Наверное, потому что и тот, кто мейнтейнит std-def тоже не имеет никакого 
> желания смотреть "какой там функционал".

У него, подозреваю, слишком много других проблем. А вот внести изменения 
в std-def и попросить смержиться - это же тривиально просто...

> 
>> Согласен, что бывают совсем странные случаи, когда лучше собрать ядро
>> рядом (сам так делал). Но в идеале надо всё равно всё это хозяйство
>> интегрировать в std-xxx (что и было сделано с v4l в своё время).
> Это работа (интеграция v4l) на пару часов.

Там было больше чем пару часов, ибо пришлось решать проблемы со сборкой 
всего остального.

Если просто накрыть в std-def патчем новый v4l - то да, пара часов. а 
если выносить v4l в отдельный пакет - то несколько больше.

Re: [devel] /etc/udev/rules.d

[Led]

On Saturday, 10 January 2009 20:19:49 Aleksey Novodvorsky wrote:
> 10 января 2009 г. 21:11 пользователь Led <ledest@gmail.com> написал:
> > On Saturday, 10 January 2009 19:59:00 Mikhail Gusarov wrote:
> >> Twas brillig at 20:57:19 10.01.2009 UTC+03 when a.e.nvdv@gmail.com did
> >> gyre and gimble:
> >>
> >>  AN> Почему так произошло -- другой вопрос.  Меня интересует
> >>  AN> общетехническая формулировка проблемы. Если бы на была
> >>  AN> зафиксирована, то было бы легче.
> >>
> >> [по ответам led, не проверено]
> >
> > [не опровергнуто]
> >
> >> RPM не совсем обоснованно выдаёт
> >> преференции определённым пакетам при установке, судя по всему - при
> >> выборе из кандидатов.
> >
> > Нет никакого выбора из кандидатов. Он требует ТОЛЬКО udev-rules - никакие
> > другие варианты даже не рассматриваются.
>
> Вам нужно сосуществование двух udev* в системе для ядер разных версий
> или взаимозаменяемость?

Второе.

-- 
Led

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On Sat, Jan 10, 2009 at 07:48:11PM +0200, Led wrote:
[...]
> 1) ПАКЕТЫ требуют /etc/udev/rules.d/

БЕЗ slash в конце.

> 2) rpm ПРИ УСТАНОВКЕ ПАКЕТА, ТРЕБУЩЕГО /etc/udev/rules.d/, считает, 
> что /etc/udev/rules.d/ может предоставлять ТОЛЬКО udev-rules И НИКТО ДРУГОЙ

Вы что-то с чем то перепутали, rpm совершенно всё равно, какой пакет
предоставляет /etc/udev/rules.d

P.S. У меня складывается устойчивое ощущение, что вы в этом году
порождаете FUD в списке рассылки.  Пожалуйста, прекратите, неприятно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michail Yakushin]

Anton Farygin wrote:
> Michael Shigorin пишет:
>> On Sat, Jan 10, 2009 at 08:59:18PM +0300, Anton Farygin wrote:
>>> Я честно - не смотрел какой там функционал, но не понимаю,
>>> почему его нельзя реализовать в std-def.
>>
>> compcache и ещё один патчик; обоим IMHO место в ванилле вообще,
>> но не уверен, что одно лишь их добавление в std-def будет
>> оптимально.  По крайней мере не факт, что результат опять влезет
>> в 16M RAM тонкого клиента.
> 
> по крайней мере расхождения будут только в конфиге, и процесс сборки
> упростится значительно.
они сводяться к времени ожидания сборки, потому что у меня есть
специальная автоматика собирающая все ядра std одним ударом под все
архитектуры(i586,x86_64) и все модули

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


Twas brillig at 21:29:11 10.01.2009 UTC+03 when silicium@altlinux.ru did gyre and gimble:

 MY> они сводяться к времени ожидания сборки, потому что у меня есть
 MY> специальная автоматика собирающая все ядра std одним ударом под все
 MY> архитектуры(i586,x86_64) и все модули

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

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michail Yakushin]

Mikhail Gusarov wrote:
> Twas brillig at 21:29:11 10.01.2009 UTC+03 when silicium@altlinux.ru did gyre and gimble:
> 
>  MY> они сводяться к времени ожидания сборки, потому что у меня есть
>  MY> специальная автоматика собирающая все ядра std одним ударом под все
>  MY> архитектуры(i586,x86_64) и все модули
> 
> А опции для ручного включения только нужной архитектуры и нужных
> модулей, для отладки, предусмотрены? Тогда и время ожидания не будет,
> мм, проблемой.
Пока нет, надо сделать, 1 ядро и отдельно модули собираются тоже просто.

Re: [devel] /etc/udev/rules.d

[Aleksey Novodvorsky]

10 января 2009 г. 21:26 пользователь Led <ledest@gmail.com> написал:
> On Saturday, 10 January 2009 20:19:49 Aleksey Novodvorsky wrote:
>> 10 января 2009 г. 21:11 пользователь Led <ledest@gmail.com> написал:
>> > On Saturday, 10 January 2009 19:59:00 Mikhail Gusarov wrote:
>> >> Twas brillig at 20:57:19 10.01.2009 UTC+03 when a.e.nvdv@gmail.com did
>> >> gyre and gimble:
>> >>
>> >>  AN> Почему так произошло -- другой вопрос.  Меня интересует
>> >>  AN> общетехническая формулировка проблемы. Если бы на была
>> >>  AN> зафиксирована, то было бы легче.
>> >>
>> >> [по ответам led, не проверено]
>> >
>> > [не опровергнуто]
>> >
>> >> RPM не совсем обоснованно выдаёт
>> >> преференции определённым пакетам при установке, судя по всему - при
>> >> выборе из кандидатов.
>> >
>> > Нет никакого выбора из кандидатов. Он требует ТОЛЬКО udev-rules - никакие
>> > другие варианты даже не рассматриваются.
>>
>> Вам нужно сосуществование двух udev* в системе для ядер разных версий
>> или взаимозаменяемость?
>
> Второе.

Спасибо, у меня больше нет вопросов.
Мне кажется, что это не совсем простая задача и я не вижу ее
общезначимости.  Но могу жестоко ошибаться, -- возражайте.

Rgrds, Алексей

>
> --
> Led
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] /etc/udev/rules.d

[Michael Shigorin]

On Sat, Jan 10, 2009 at 08:26:13PM +0200, Led wrote:
> > Вам нужно сосуществование двух udev* в системе для ядер
> > разных версий или взаимозаменяемость?
> Второе.

А смысл?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 21:29:11 10.01.2009 UTC+03 when silicium@altlinux.ru did gyre and gimble:
> 
>  MY> они сводяться к времени ожидания сборки, потому что у меня есть
>  MY> специальная автоматика собирающая все ядра std одним ударом под все
>  MY> архитектуры(i586,x86_64) и все модули
> 
> А опции для ручного включения только нужной архитектуры и нужных
> модулей, для отладки, предусмотрены? Тогда и время ожидания не будет,
> мм, проблемой.

Я это делал одной командой. Одно ядро + модули, потом только модули. В 
общем - всё было просто замечательно ;)

Честно - мне очень хотелось тоже делать своё ядро.. но внимательно 
посмотрев список изменений - себе дороже. Зачем, если проще их было 
забросить в std-def, к тому же они реально полезны сообществу, а не 
только мне.

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

Но всё-таки лучше делать это на максимально приближенной к std-def 
кодовой базе, а не плодить свои отдельно-живущие сущности. Банально 
легче в дальнейшем поддерживать.

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On Sat, Jan 10, 2009 at 08:55:01PM +0300, Anton Farygin wrote:
>> Это было разумно, когда ядра собирал kernel hacker, и любому было ясно что
>> все что будет собирать он сам для себя будет заведомо хуже.
>> Сейчас ситуация другая -- имеющиеся ядра устраивают не всех.
AF> И кто мешает прислать патч мантейнеру ?

Вот ты выясни почему wks лежит отдельно, вместо дружной совместной работы
silicium@ и lakostis@.

Или почему led-tc это совсем не то же самое что std-def.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On Sat, Jan 10, 2009 at 09:19:39PM +0300, Anton Farygin wrote:

AF> по крайней мере расхождения будут только в конфиге, и процесс сборки 
AF> упростится значительно.

Есть и еще одна проблема. Люди которым нужно чтобы было надежно, а не
чтобы "быстрее в светлое будущее".

Я вон до сих пор на сервера ставил, ставлю, и буду ставить -- ovz-smp из
Server 4.0. И ядра 2.6.18 до сих пор актуальны.

Я категорически отказываюсь понимать политику насильно всех в светлое
будущее, и отрывание поддержки старых ядер в Сизифе. Боюсь что дальнейшее
продолжение этой политики приведет к тому, что я сяду на тот же 5.0 и
после этого полностью прекращу работу как мантейнера в _сизифе_,
ограничившись тем бранчем который для меня работает.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Sat, Jan 10, 2009 at 08:59:18PM +0300, Anton Farygin wrote:

AF> Поддержка ядра - это процедура, требующая доволно приличного времени и 
AF> сил, не говоря уже про голову и руки.
AF> То, что не все выдерживают - это нормальное явление.

Насколько я вижу -- дело не в "не выдерживают", а в совершенно другой
плоскости.

К примеру лично я отказался от идеи поддерживать свои ядра (да, на базе
std-def со слегка другим конфигом, но все же) -- после того как module
templates унесли в git, который теперь размазан по десятку репо.

AF> Думаю, что led-tc возможно перетащить на 2.6.27, с 2.6.22.. просто у 
AF> Led'а на это в данный момент нет времени. Отсюда и грабли.

Кто это будет делать, и кто ему за это заплатит?

AF> Я честно - не смотрел какой там функционал, но не понимаю, почему его 
AF> нельзя реализовать в std-def.
AF> Согласен, что бывают совсем странные случаи, когда лучше собрать ядро 
AF> рядом (сам так делал). Но в идеале надо всё равно всё это хозяйство 
AF> интегрировать в std-xxx (что и было сделано с v4l в своё время).

Да, ты прав.

Но при этом если я собрал ядро рядом -- у меня должна быть возможность его
использовать, а не пересобирать полсизифа вместе с ним.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] /etc/udev/rules.d

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Sat, Jan 10, 2009 at 08:19:08PM +0200, Led wrote:

L> Я вас прекрасно понимаю. Если бы мне такое про rpm сказали - я бы рассмеялся в 
L> лицо, потому что "обучать ЭТОМУ" rpm - как минимум смешно.

Можно последовательность действий в hasher chroot которая приведет к
возникновению той проблемы о которой вы говорите?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michail Yakushin]

Денис Смирнов wrote:
> On Sat, Jan 10, 2009 at 08:55:01PM +0300, Anton Farygin wrote:
>>> Это было разумно, когда ядра собирал kernel hacker, и любому было ясно что
>>> все что будет собирать он сам для себя будет заведомо хуже.
>>> Сейчас ситуация другая -- имеющиеся ядра устраивают не всех.
> AF> И кто мешает прислать патч мантейнеру ?
> 
> Вот ты выясни почему wks лежит отдельно, вместо дружной совместной работы
> silicium@ и lakostis@.
Здесь проблема в голове мейнтейнера, возможно обоих. Мы так и не смогли
договориться, вообще ни о чём.
> Или почему led-tc это совсем не то же самое что std-def.
Там есть пачи, который нужны собственно для tc но в других случаях
скорее всего вредны. Но мне led@ из не предлагал в std добавлять. 2
предлагал, 1 мне не понравился, 1 собран как модуль.
Так что товарищи, предлагайте пачи, нормальные я добавлю.

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michail Yakushin]

Денис Смирнов wrote:
> On Sat, Jan 10, 2009 at 09:19:39PM +0300, Anton Farygin wrote:
> 
> AF> по крайней мере расхождения будут только в конфиге, и процесс сборки 
> AF> упростится значительно.
> 
> Есть и еще одна проблема. Люди которым нужно чтобы было надежно, а не
> чтобы "быстрее в светлое будущее".
К сожалению светлое будщиее неизбежно, а для функцианирования новых фич,
иногда ломается совместимось.
> Я вон до сих пор на сервера ставил, ставлю, и буду ставить -- ovz-smp из
> Server 4.0. И ядра 2.6.18 до сих пор актуальны.
Пока они работают на новом железе. Но это скоро закончится.
> Я категорически отказываюсь понимать политику насильно всех в светлое
> будущее, и отрывание поддержки старых ядер в Сизифе. Боюсь что дальнейшее
> продолжение этой политики приведет к тому, что я сяду на тот же 5.0 и
> после этого полностью прекращу работу как мантейнера в _сизифе_,
> ограничившись тем бранчем который для меня работает.
> 

4.0 ещё никто не выкидывал, да и с vz и прочим в 27м ядре или позже как
то разрулиться.

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michail Yakushin]

Денис Смирнов wrote:

> К примеру лично я отказался от идеи поддерживать свои ядра (да, на базе
> std-def со слегка другим конфигом, но все же) -- после того как module
> templates унесли в git, который теперь размазан по десятку репо.
кстати std-ll было сделано практически для тебя, как основного
телефониста, поэтому если там что-то не нравиться можно смело предлагать.
> AF> Думаю, что led-tc возможно перетащить на 2.6.27, с 2.6.22.. просто у 
> AF> Led'а на это в данный момент нет времени. Отсюда и грабли.
> 
> Кто это будет делать, и кто ему за это заплатит?
> 
> AF> Я честно - не смотрел какой там функционал, но не понимаю, почему его 
> AF> нельзя реализовать в std-def.
> AF> Согласен, что бывают совсем странные случаи, когда лучше собрать ядро 
> AF> рядом (сам так делал). Но в идеале надо всё равно всё это хозяйство 
> AF> интегрировать в std-xxx (что и было сделао с v4l в своё время).
> 
> Да, ты прав.
> 
> Но при этом если я собрал ядро рядом -- у меня должна быть возможность его
> использовать, а не пересобирать полсизифа вместе с ним.
К сожалению границы совместимости между софтом не от - бесконечности до
+  бесконечности, наш glibc например не сможет, вообще не сможет
работать с ядрами 2.4, если туда не забекпортить поддержку некоторых
системных вызовов.

Вообще всякие проекты которые выпускают свои модули к ядру, или тем
более делают пачи к ядру, но делают их к древним ядрам создают множество
проблем. Потому что древние ядра плохо работают на новом железе, а старе
модули под новые ядра не соберёшь, или хуже того они собираются но хрен
знает почему не работают. С одной стороны это и проблема апстрима ядра,
API там меняется со страшной силой, но и проблема самих таких проектов.
Кстати по моим наблюдениям проекты которые не успевают за апстримом
ядра, обычно слишком глубоко в него влезли. Что xen,что ovz,что openssi
последний вообще сначала залез в дебри, потом не осилил идти в ногу с
апстримом(даже на 1-2 версии позади), в результате загнулся.
Одно хорошо что xen и vz осилили таки влится в основную ветку, но их
сильно пришлось перерабатываться что говорит о количестве хаков в обоих.

Re: [devel] /etc/udev/rules.d

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

AN> Спасибо, у меня больше нет вопросов.
AN> Мне кажется, что это не совсем простая задача и я не вижу ее
AN> общезначимости.  Но могу жестоко ошибаться, -- возражайте.

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

Например ovz-smp полноценный -- это 2.6.18, увы.

Аналогичная ситуация бывает и в других ситуациях.

Однако разработчику нужно иметь возможность сидеть на сизифе, и выполнять
свои задачи сидя на сизифе.

Таким образом поддержка относительно старых ядер в Сизифе должна как-то
обеспечиваться, при этом желательно поддерживать ядра хотя бы 1-2 летней
давности, а в идеале -- 3-х летней.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Sun, Jan 11, 2009 at 09:34:53AM +0300, Michail Yakushin wrote:

>> Вот ты выясни почему wks лежит отдельно, вместо дружной совместной работы
>> silicium@ и lakostis@.
MY> Здесь проблема в голове мейнтейнера, возможно обоих. Мы так и не смогли
MY> договориться, вообще ни о чём.

Мне непонятно зачем вам договариваться. Ты собираешь std-*, Костя wks-*.
То, что Косте категорически не нравятся std-* -- ну что-ж, его право
собирать что-то свое, а если пользователи начнут голосовать ногами за
использование wks -- у тебя будет повод даже не договариваться с ним, а
просто подсмотреть что он такого делает что пользователям нравится.

>> Или почему led-tc это совсем не то же самое что std-def.
MY> Там есть пачи, который нужны собственно для tc но в других случаях
MY> скорее всего вредны. Но мне led@ из не предлагал в std добавлять. 2
MY> предлагал, 1 мне не понравился, 1 собран как модуль.
MY> Так что товарищи, предлагайте пачи, нормальные я добавлю.

И так -- кроме std-* в Сизифе все-таки нужны ядра которые собирают другие
мантейнеры. И хотя led@ не является крутым kernel hacker'ом, для его
задачи led-tc -- лучше. И это нормальная практика.

Позиция "у нас должно быть одно ядро для всех" которая озвучивается в этой
рассылке мне не нравится.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

On Sun, Jan 11, 2009 at 09:37:42AM +0300, Michail Yakushin wrote:

>> Есть и еще одна проблема. Люди которым нужно чтобы было надежно, а не
>> чтобы "быстрее в светлое будущее".
MY> К сожалению светлое будщиее неизбежно, а для функцианирования новых фич,
MY> иногда ломается совместимось.

Это я прекрасно понимаю. Поэтому всего лишь хочу чтобы рядом с супер новым
std-def лежали и другие ядра -- более консервативных версий. Вон, многие
говорят что для них лучшим было 2.6.25. Почему под отдельным flavour оно
не может жить в Сизифе?

Опять же. Я прекрасно понимаю что мантейнер std-def не железный ;) И
поэтому то самое .25 вполне возможно будет собирать кто-то другой.

Конкретно мне не нравится что сейчас будет сломана совместимость Сизифа со
старыми ядрами.

>> Я вон до сих пор на сервера ставил, ставлю, и буду ставить -- ovz-smp из
>> Server 4.0. И ядра 2.6.18 до сих пор актуальны.
MY> Пока они работают на новом железе. Но это скоро закончится.

Однако то самое старое железо еще не скоро уйдет на свалку.

>> Я категорически отказываюсь понимать политику насильно всех в светлое
>> будущее, и отрывание поддержки старых ядер в Сизифе. Боюсь что дальнейшее
>> продолжение этой политики приведет к тому, что я сяду на тот же 5.0 и
>> после этого полностью прекращу работу как мантейнера в _сизифе_,
>> ограничившись тем бранчем который для меня работает.
MY> 4.0 ещё никто не выкидывал, да и с vz и прочим в 27м ядре или позже как
MY> то разрулиться.

Вот мы и начинаем приходить к тому, что на рабочей машине приходится
пользоваться старыми дистрибутивами. Только в этом случае
собирать/тестировать пакеты в Сизиф становится слишком сложным, чтобы это
делать бесплатно.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

On Sun, Jan 11, 2009 at 09:49:13AM +0300, Michail Yakushin wrote:

>> К примеру лично я отказался от идеи поддерживать свои ядра (да, на базе
>> std-def со слегка другим конфигом, но все же) -- после того как module
>> templates унесли в git, который теперь размазан по десятку репо.
MY> кстати std-ll было сделано практически для тебя, как основного
MY> телефониста, поэтому если там что-то не нравиться можно смело предлагать.

Спасибо, сейчас все нравится -- я на нем дистрибутив собирать пытаюсь
сейчас :)

Ты только не забудь пересобрать zaptel для ovz-smp если еще не ;)

>> Но при этом если я собрал ядро рядом -- у меня должна быть возможность его
>> использовать, а не пересобирать полсизифа вместе с ним.
MY> К сожалению границы совместимости между софтом не от - бесконечности до
MY> +  бесконечности, наш glibc например не сможет, вообще не сможет
MY> работать с ядрами 2.4, если туда не забекпортить поддержку некоторых
MY> системных вызовов.

Логично. Но, насколько я помню, Дима обновил glibc когда прошло уже
_очень_ много времени с тех пор как вышло 2.6.*.

Увы, изредка такие поломки делать приходится.

MY> Одно хорошо что xen и vz осилили таки влится в основную ветку, но их
MY> сильно пришлось перерабатываться что говорит о количестве хаков в обоих.

Ну это понятно :) Виртуализация это один большой хак. Только ovz пока еще
не влилась нормально :(

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]


Twas brillig at 02:50:20 12.01.2009 UTC+03 when mithraen@altlinux.ru did gyre and gimble:

 ДС> Позиция "у нас должно быть одно ядро для всех" которая озвучивается
 ДС> в этой рассылке мне не нравится.

"Один codebase для всех" и "одно ядро для всех" - это совершенно разные
понятия. Озвучивается в рассылке первое, а не второе. Идея состоит не в
"std-def для всех, даром, и чтобы никто не ушёл обиженным", а в том,
чтобы по сорок раз не делать одну и ту же работу: led мог
сосредоточиться на патчах для TS, ты - на low-latency, и т.д.

Впрочем, поскольку git pull друг у друга локальные кернел-мейнтейнеры не
признают, в отличие от git clone, то это всё теоретизирование :)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Monday, 12 January 2009 01:59:16 Mikhail Gusarov wrote:
> Twas brillig at 02:50:20 12.01.2009 UTC+03 when mithraen@altlinux.ru did
> gyre and gimble:
>
>  ДС> Позиция "у нас должно быть одно ядро для всех" которая озвучивается
>  ДС> в этой рассылке мне не нравится.
>
> "Один codebase для всех" и "одно ядро для всех" - это совершенно разные
> понятия. Озвучивается в рассылке первое, а не второе. Идея состоит не в
> "std-def для всех, даром, и чтобы никто не ушёл обиженным", а в том,
> чтобы по сорок раз не делать одну и ту же работу: led мог
> сосредоточиться на патчах для TS, ты - на low-latency, и т.д.

"Автомобиль может быть любого цвета, если этот цвет - чёрный" (c) H.Ford
Т.е.: "Ладно, разрешаются разные ядра... Но только если они 2.6.27"

>
> Впрочем, поскольку git pull друг у друга локальные кернел-мейнтейнеры не
> признают, в отличие от git clone, то это всё теоретизирование :)



-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michail Yakushin]

Денис Смирнов wrote:
> On Sun, Jan 11, 2009 at 09:37:42AM +0300, Michail Yakushin wrote:
> 
>>> Есть и еще одна проблема. Люди которым нужно чтобы было надежно, а не
>>> чтобы "быстрее в светлое будущее".
> MY> К сожалению светлое будщиее неизбежно, а для функцианирования новых фич,
> MY> иногда ломается совместимось.
> 
> Это я прекрасно понимаю. Поэтому всего лишь хочу чтобы рядом с супер новым
> std-def лежали и другие ядра -- более консервативных версий. Вон, многие
> говорят что для них лучшим было 2.6.25. Почему под отдельным flavour оно
> не может жить в Сизифе?
Да я не против, кто бы занялся. И вообще не против более 1 ядра в сизифе.
Вот что странно, желющих собирать 28е ядро почему-то больше чем желющих
собирать 18е.
Хотя и если кто-то собирёт 28 и выложит в сизиф ничего плохого не будет.

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]


Twas brillig at 02:07:19 12.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> "Автомобиль может быть любого цвета, если этот цвет - чёрный" (c)
 L> H.Ford Т.е.: "Ладно, разрешаются разные ядра... Но только если они
 L> 2.6.27"

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

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Mon, Jan 12, 2009 at 08:27:00AM +0300, Michail Yakushin wrote:

>> Это я прекрасно понимаю. Поэтому всего лишь хочу чтобы рядом с супер новым
>> std-def лежали и другие ядра -- более консервативных версий. Вон, многие
>> говорят что для них лучшим было 2.6.25. Почему под отдельным flavour оно
>> не может жить в Сизифе?
MY> Да я не против, 

Я в курсе :) Уж к кому, так к тебе претензий меньше всего.

MY> кто бы занялся. И вообще не против более 1 ядра в сизифе.
MY> Вот что странно, желющих собирать 28е ядро почему-то больше чем желющих
MY> собирать 18е.
MY> Хотя и если кто-то собирёт 28 и выложит в сизиф ничего плохого не будет.

Лично я среагировал на объявление о том что старые ядра теперь не будут
поддерживаться udev'ом.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Mon, Jan 12, 2009 at 05:59:16AM +0600, Mikhail Gusarov wrote:

MG> "Один codebase для всех" и "одно ядро для всех" - это совершенно разные
MG> понятия. Озвучивается в рассылке первое, а не второе. Идея состоит не в
MG> "std-def для всех, даром, и чтобы никто не ушёл обиженным", а в том,
MG> чтобы по сорок раз не делать одну и ту же работу: led мог
MG> сосредоточиться на патчах для TS, ты - на low-latency, и т.д.

Вопрос еще в том что люди хотят не только разных конфигов/патчей, но и
разных _версий_.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]


Twas brillig at 10:04:02 13.01.2009 UTC+03 when mithraen@altlinux.ru did gyre and gimble:

 ДС> Вопрос еще в том что люди хотят не только разных конфигов/патчей,
 ДС> но и разных _версий_.

Ну и замечательно. Зачем для этого "стругать в уголке"?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Michael Shigorin]

On Mon, Jan 12, 2009 at 02:46:41AM +0300, Денис Смирнов wrote:
> Таким образом поддержка относительно старых ядер в Сизифе
> должна как-то обеспечиваться, при этом желательно поддерживать
> ядра хотя бы 1-2 летней давности, а в идеале -- 3-х летней.

Эт здорово, вот только _разработчикам_ udev, скорее, не настолько
близко, как тебе...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] [JT] kernel collab (or the abscence thereof)

[Michael Shigorin]

On Mon, Jan 12, 2009 at 02:50:20AM +0300, Денис Смирнов wrote:
> [...] у тебя будет повод даже не договариваться с ним, а просто
> подсмотреть что он такого делает что пользователям нравится.

Ещё один маленький, но важный момент: подсматривая и принимая,
стоит упоминать в ченжлогах, откуда идея или реализация.

Просто по-человечески помогает.

> И так -- кроме std-* в Сизифе все-таки нужны ядра которые
> собирают другие мантейнеры. И хотя led@ не является крутым
> kernel hacker'ом, для его задачи led-tc -- лучше. И это
> нормальная практика.

JFYI, для меня является достаточно крутым. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michael Shigorin]

On Mon, Jan 12, 2009 at 09:43:45PM +0600, Mikhail Gusarov wrote:
> > "Автомобиль может быть любого цвета, если этот цвет - чёрный"
> > (c) H.Ford Т.е.: "Ладно, разрешаются разные ядра... Но только
> > если они 2.6.27"
> Прошу прекратить FUD

Ты (и Дима тоже) неправ: это не FUD (fear, uncertainity and
doubt), а всего лишь передёргивание.  Потому как ">2.6.22" -- 
иное условие, нежели "=2.6.27".

> Аргументы про udev, до получения ответов на заданные в теме про
> udev вопросы, не принимаются.

Насколько понимаю, в итоге не будет ни аргументов, ни попыток
решить эту ситуацию (или породившую её).  Clap-clap-clap всем.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]


Twas brillig at 23:24:31 14.01.2009 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 MS> Насколько понимаю, в итоге не будет ни аргументов, ни попыток
 MS> решить эту ситуацию (или породившую её).  Clap-clap-clap всем.

Пока led не расскажет, в чём вообще состоит проблема - не будет. По
результатам прошлого обсуждения

1) разоблачено несколько мифов,
2) задано несколько вопросов, не породивших ответа.

Больше ничего.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Led]

On Wednesday, 14 January 2009 23:29:43 Mikhail Gusarov wrote:
> Twas brillig at 23:24:31 14.01.2009 UTC+02 when mike@osdn.org.ua did gyre
> and gimble:
>
>  MS> Насколько понимаю, в итоге не будет ни аргументов, ни попыток
>  MS> решить эту ситуацию (или породившую её).  Clap-clap-clap всем.
>
> Пока led не расскажет, в чём вообще состоит проблема - не будет. По
> результатам прошлого обсуждения
>
> 1) разоблачено несколько мифов,

Вы себе льстите:)
Для того, чтобы "разоблачить", нужно сделать пакет udevXYZ и установить его 
(со всеми субпакетами) (без бубна) в систему с оригинальным udev.

> 2) задано несколько вопросов, не породивших ответа.

Вопросов я не заметил. В основном - т.н. "разоблачения":)

На всякий случай замечу: у меня есть готовая схема и пакеты, для обеспечения 
установки алтернативы вместо основного udev. Эта схема не ломает так 
полюбившуюся вам схему с костылями в rpm, только требует внесения 
микроскопического изменения в 0common-files.req.list и в пакете udev. Схема 
проверена и работает, возможно она будет применяться в одном из 
Sisyphus-based дистрибутиве.

-- 
Led

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]


Twas brillig at 00:04:48 15.01.2009 UTC+02 when ledest@gmail.com did gyre and gimble:

 L> Вопросов я не заметил. В основном - т.н. "разоблачения":)

Да, разумеется. Для наведения FUD-а вопросы замечать не требуется.

 L> На всякий случай замечу: у меня есть готовая схема и пакеты, для
 L> обеспечения установки алтернативы вместо основного udev.

Show me the code.

Вообще, мне уже наплевать. Зачем я пытаюсь из вас что-то вытянуть? Вам
это явно не нужно, вы предпочитаете считать Сизиф говном и разводить
FUD.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] /etc/udev/rules.d

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

On Thu, Jan 15, 2009 at 12:04:48AM +0200, Led wrote:
[...]
> На всякий случай замечу: у меня есть готовая схема и пакеты, для обеспечения 
> установки алтернативы вместо основного udev.

Откройте в bugzilla.a.o баг, дайте там краткое описание проблемы (суммируя
констуктивную часть дискуссии), дайте ссылку на git-коммиты (альтернативно:
приложите патчи), реализующие ваше предложение.

Я не уверен, что проблема стоит того, чтобы её решать, но если кто-то всё
же решит, что она того стоит, то с помощью информации bugzilla.a.o этот
кто-то получит шанс.

P.S.  Как тяжело среди ваших писем выявлять конструктив последнее вермя, однако.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Aleksey Novodvorsky]

15 января 2009 г. 1:04 пользователь Led <ledest@gmail.com> написал:
> On Wednesday, 14 January 2009 23:29:43 Mikhail Gusarov wrote:
>> Twas brillig at 23:24:31 14.01.2009 UTC+02 when mike@osdn.org.ua did gyre
>> and gimble:
>>
>>  MS> Насколько понимаю, в итоге не будет ни аргументов, ни попыток
>>  MS> решить эту ситуацию (или породившую её).  Clap-clap-clap всем.
>>
>> Пока led не расскажет, в чём вообще состоит проблема - не будет. По
>> результатам прошлого обсуждения
>>
>> 1) разоблачено несколько мифов,
>
> Вы себе льстите:)
> Для того, чтобы "разоблачить", нужно сделать пакет udevXYZ и установить его
> (со всеми субпакетами) (без бубна) в систему с оригинальным udev.
>
>> 2) задано несколько вопросов, не породивших ответа.
>
> Вопросов я не заметил. В основном - т.н. "разоблачения":)
>
> На всякий случай замечу: у меня есть готовая схема и пакеты, для обеспечения
> установки алтернативы вместо основного udev. Эта схема не ломает так
> полюбившуюся вам схему с костылями в rpm, только требует внесения
> микроскопического изменения в 0common-files.req.list и в пакете udev. Схема
> проверена и работает, возможно она будет применяться в одном из
> Sisyphus-based дистрибутиве.

Того, что не опубликовано, не существует. По крайней мере, для Сизифа
и в этом списке рассылки.
Если есть общая проблема, то сформулируйте ее без наездов и
передергиваний (я согласен с ldv, что мы наблюдали именно FUD, но
пользуюсь терминологией mike@). Если это проблема конкретной
разработки, то объясните в чем она. Если последнее невозможно, то
правьте сами, можете предложить код мейнтейнеру. Анонсы решения
непонятной проблемы без кода мне кажутся здесь некорректными.
Есть ли другие мнения?

Rgrds, Алексей

>
> --
> Led
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] /etc/udev/rules.d

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

On Wed, Jan 14, 2009 at 11:18:21PM +0200, Michael Shigorin wrote:
>> Таким образом поддержка относительно старых ядер в Сизифе
>> должна как-то обеспечиваться, при этом желательно поддерживать
>> ядра хотя бы 1-2 летней давности, а в идеале -- 3-х летней.
MS> Эт здорово, вот только _разработчикам_ udev, скорее, не настолько
MS> близко, как тебе...

Разработчики идут лесом, ибо мы к счастью _упаковщики_ udev. И никто нам
не запрещает сделать альтернативы для udev.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michael Shigorin]

On Thu, Jan 15, 2009 at 03:29:43AM +0600, Mikhail Gusarov wrote:
>  MS> Насколько понимаю, в итоге не будет ни аргументов, ни попыток
>  MS> решить эту ситуацию (или породившую её).  Clap-clap-clap всем.
> Пока led не расскажет, в чём вообще состоит проблема
> - не будет. По результатам прошлого обсуждения
> 1) разоблачено несколько мифов,

Ты купился на слова raorn@, причём скорее напрасно.

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

> 2) задано несколько вопросов, не породивших ответа.
> Больше ничего.

Ещё пройдено несколько кругов по пачке смежных вопросов,
потому как вы с led@ слишком быстро читаете почту.

Ничего сильно страшного, просто когда добрался почитать --
пожал плечами и подумал, что смыслу в этих "голубых касках"
было ноль.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] *sigh*

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

On Thu, Jan 15, 2009 at 04:07:57AM +0600, Mikhail Gusarov wrote:
> Вообще, мне уже наплевать. Зачем я пытаюсь из вас что-то
> вытянуть?

Не умеешь -- не берись.

> Вам это явно не нужно, вы предпочитаете считать Сизиф говном
> и разводить FUD.

Не ври.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]


Twas brillig at 00:34:54 17.01.2009 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 MS> Ты купился на слова raorn@, причём скорее напрасно.

И там слова, и там слова (не raorn, а ldv). Вообще-то, доказывать вину
должно обвинение, а не защита ;)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] *sigh*

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]


Twas brillig at 00:35:55 17.01.2009 UTC+02 when mike@osdn.org.ua did gyre and gimble:

 MS> Не умеешь -- не берись.

Это допрос партизана, а не конструктивная работа.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Aleksey Novodvorsky]

17 января 2009 г. 1:34 пользователь Michael Shigorin <mike@osdn.org.ua> написал:
> On Thu, Jan 15, 2009 at 03:29:43AM +0600, Mikhail Gusarov wrote:
>>  MS> Насколько понимаю, в итоге не будет ни аргументов, ни попыток
>>  MS> решить эту ситуацию (или породившую её).  Clap-clap-clap всем.
>> Пока led не расскажет, в чём вообще состоит проблема
>> - не будет. По результатам прошлого обсуждения
>> 1) разоблачено несколько мифов,
>
> Ты купился на слова raorn@, причём скорее напрасно.
>
> Вообще вопросы явного и неявного доверия в команде уже начинают
> вылазить довольно разнообразными боками.

А можно без морализаторства написать в bugzilla суть ошибки? Ну и патч
приложить, если есть. ldv@ все ясно написал.

Rgrds, Алексей

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michael Shigorin]

On Thu, Jan 15, 2009 at 07:46:41AM +0300, Aleksey Novodvorsky wrote:
> Если последнее невозможно, то правьте сами, можете предложить
> код мейнтейнеру. Анонсы решения непонятной проблемы без кода
> мне кажутся здесь некорректными.  Есть ли другие мнения?

Алексей, гляньте в bugzilla баги, развешенные за последние
годы Сашей.  Время от времени пытаюсь убедить его, что вовсе
необязательно к толковому багрепорту нарабатывать ещё и
проверенный патч, но пока скорее наблюдается глухое отчаяние
по поводу того, что всем обычно наплевать.
Потому как перегруженные.

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Aleksey Novodvorsky]

17 января 2009 г. 1:50 пользователь Michael Shigorin <mike@osdn.org.ua> написал:
> On Thu, Jan 15, 2009 at 07:46:41AM +0300, Aleksey Novodvorsky wrote:
>> Если последнее невозможно, то правьте сами, можете предложить
>> код мейнтейнеру. Анонсы решения непонятной проблемы без кода
>> мне кажутся здесь некорректными.  Есть ли другие мнения?
>
> Алексей, гляньте в bugzilla баги, развешенные за последние
> годы Сашей.  Время от времени пытаюсь убедить его, что вовсе
> необязательно к толковому багрепорту нарабатывать ещё и
> проверенный патч, но пока скорее наблюдается глухое отчаяние
> по поводу того, что всем обычно наплевать.
> Потому как перегруженные.

Вы сами поняли о чем речь, где _ошибка_ и почему  важно ее срочно
исправлять? Если да -- напишите в bugzilla,  пожалуйста.  Если нет, --
то о чем разговор?

Rgrds, Алексей

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michael Shigorin]

On Sat, Jan 17, 2009 at 01:56:42AM +0300, Aleksey Novodvorsky wrote:
> >> Если последнее невозможно, то правьте сами, можете
> >> предложить код мейнтейнеру. Анонсы решения непонятной
> >> проблемы без кода мне кажутся здесь некорректными.
> >> Есть ли другие мнения?
> > Алексей, гляньте в bugzilla баги, развешенные за последние
> > годы Сашей.

Здесь написано именно то, что написано: если хотите понять,
почему развешивающие баги с патчами люди переходят в
неконструктивную позицию -- почитайте их баги.

> > Время от времени пытаюсь убедить его, что вовсе необязательно
> > к толковому багрепорту нарабатывать ещё и проверенный патч,
> > но пока скорее наблюдается глухое отчаяние по поводу того,
> > что всем обычно наплевать.  Потому как перегруженные.
> Вы сами поняли о чем речь

Да, конечно.

> где _ошибка_ и почему  важно ее срочно исправлять?

В miscommunication.

> Если да -- напишите в bugzilla,  пожалуйста.

Я могу писать об этом в местное спортлото с тем же успехом, увы.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Aleksey Novodvorsky]

17 января 2009 г. 17:30 пользователь Michael Shigorin
<mike@osdn.org.ua> написал:
> On Sat, Jan 17, 2009 at 01:56:42AM +0300, Aleksey Novodvorsky wrote:
>> >> Если последнее невозможно, то правьте сами, можете
>> >> предложить код мейнтейнеру. Анонсы решения непонятной
>> >> проблемы без кода мне кажутся здесь некорректными.
>> >> Есть ли другие мнения?
>> > Алексей, гляньте в bugzilla баги, развешенные за последние
>> > годы Сашей.
>
> Здесь написано именно то, что написано: если хотите понять,
> почему развешивающие баги с патчами люди переходят в
> неконструктивную позицию -- почитайте их баги.
>
>> > Время от времени пытаюсь убедить его, что вовсе необязательно
>> > к толковому багрепорту нарабатывать ещё и проверенный патч,
>> > но пока скорее наблюдается глухое отчаяние по поводу того,
>> > что всем обычно наплевать.  Потому как перегруженные.
>> Вы сами поняли о чем речь
>
> Да, конечно.
>
>> где _ошибка_ и почему  важно ее срочно исправлять?
>
> В miscommunication.

Есть ли _техническая_ бага? Да или нет?
Ясна ли она Вам? Да или нет?

>
>> Если да -- напишите в bugzilla,  пожалуйста.
>
> Я могу писать об этом в местное спортлото с тем же успехом, увы.

Вот это мы слышим с начала обсуждения. Именно потому оно бесплодно.
Вас уже все просят описать багу: ldv@, dottedmag@, я. Сколько же можно
препираться впустую?

Rgrds, Алексей
>
> --
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>  ------ Linux.Kiev http://www.linux.kiev.ua/
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michael Shigorin]

On Sat, Jan 17, 2009 at 05:45:25PM +0300, Aleksey Novodvorsky wrote:
> >> >> Если последнее невозможно, то правьте сами, можете
> >> >> предложить код мейнтейнеру. Анонсы решения непонятной
> >> >> проблемы без кода мне кажутся здесь некорректными.
> >> >> Есть ли другие мнения?
> >> > Алексей, гляньте в bugzilla баги, развешенные за последние
> >> > годы Сашей.
> > Здесь написано именно то, что написано: если хотите понять,
> > почему развешивающие баги с патчами люди переходят в
> > неконструктивную позицию -- почитайте их баги.
> >> > Время от времени пытаюсь убедить его, что вовсе
> >> > необязательно к толковому багрепорту нарабатывать ещё и
> >> > проверенный патч, но пока скорее наблюдается глухое
> >> > отчаяние по поводу того, что всем обычно наплевать.
> >> > Потому как перегруженные.
> >> Вы сами поняли о чем речь
> > Да, конечно.
> >> где _ошибка_ и почему  важно ее срочно исправлять?
> > В miscommunication.
> Есть ли _техническая_ бага? Да или нет?

Не знаю.

> Ясна ли она Вам? Да или нет?

Нет.

> >> Если да -- напишите в bugzilla,  пожалуйста.
> > Я могу писать об этом в местное спортлото с тем же успехом, увы.
> Вот это мы слышим с начала обсуждения. Именно потому оно
> бесплодно.

Алексей, Вас подписывать на баги, которые по моему скромному
мнению могут приводить к подобным обсуждениям?  Да или нет?

> Вас уже все просят описать багу: ldv@, dottedmag@, я.
> Сколько же можно препираться впустую?

Я могу пойти на принцип, залезть, разобраться во всём сам
и выдать на орехи всем подряд.

Пока мне кажется, что проблема с udev технически может быть
проблемой, но её решение может быть пирровой победой и поэтому
ходить на принципы смыслу нет.

Пока кажется более разумным потратить усилия на то, чтобы
выяснить происхождение "4.4.2" вот здесь:

rpmlib(PayloadIsLzma) <= 4.4.2-1

или деталей реализации файлтриггеров, поскольку по тому,
что слышу -- патч из мандривы там заметно переработан.

PS: можете радостно заявить "оппонент слил", мне потихоньку
становится так же безразлично, как и Саше.  И вообще я больше
не менеджер "Медиа Мэджик", а обычный системный администратор.

И не собираюсь и далее проводить сутки за почтой и патчами.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Aleksey Novodvorsky]

17 января 2009 г. 19:27 пользователь Michael Shigorin
<mike@osdn.org.ua> написал:
> On Sat, Jan 17, 2009 at 05:45:25PM +0300, Aleksey Novodvorsky wrote:
>> >> >> Если последнее невозможно, то правьте сами, можете
>> >> >> предложить код мейнтейнеру. Анонсы решения непонятной
>> >> >> проблемы без кода мне кажутся здесь некорректными.
>> >> >> Есть ли другие мнения?
>> >> > Алексей, гляньте в bugzilla баги, развешенные за последние
>> >> > годы Сашей.
>> > Здесь написано именно то, что написано: если хотите понять,
>> > почему развешивающие баги с патчами люди переходят в
>> > неконструктивную позицию -- почитайте их баги.
>> >> > Время от времени пытаюсь убедить его, что вовсе
>> >> > необязательно к толковому багрепорту нарабатывать ещё и
>> >> > проверенный патч, но пока скорее наблюдается глухое
>> >> > отчаяние по поводу того, что всем обычно наплевать.
>> >> > Потому как перегруженные.
>> >> Вы сами поняли о чем речь
>> > Да, конечно.
>> >> где _ошибка_ и почему  важно ее срочно исправлять?
>> > В miscommunication.
>> Есть ли _техническая_ бага? Да или нет?
>
> Не знаю.
>
>> Ясна ли она Вам? Да или нет?
>
> Нет.
>
>> >> Если да -- напишите в bugzilla,  пожалуйста.
>> > Я могу писать об этом в местное спортлото с тем же успехом, увы.
>> Вот это мы слышим с начала обсуждения. Именно потому оно
>> бесплодно.
>
> Алексей, Вас подписывать на баги, которые по моему скромному
> мнению могут приводить к подобным обсуждениям?  Да или нет?

Да.

>
>> Вас уже все просят описать багу: ldv@, dottedmag@, я.
>> Сколько же можно препираться впустую?
>
> Я могу пойти на принцип, залезть, разобраться во всём сам
> и выдать на орехи всем подряд.

Как Вам будет угодно.

>
> Пока мне кажется, что проблема с udev технически может быть
> проблемой, но её решение может быть пирровой победой и поэтому
> ходить на принципы смыслу нет.
>
> Пока кажется более разумным потратить усилия на то, чтобы
> выяснить происхождение "4.4.2" вот здесь:
>
> rpmlib(PayloadIsLzma) <= 4.4.2-1
>
> или деталей реализации файлтриггеров, поскольку по тому,
> что слышу -- патч из мандривы там заметно переработан.

Возможно.
>
> PS: можете радостно заявить "оппонент слил", мне потихоньку
> становится так же безразлично, как и Саше.  И вообще я больше
> не менеджер "Медиа Мэджик", а обычный системный администратор.
>
> И не собираюсь и далее проводить сутки за почтой и патчами.
>

Михаил, поймите, это Вы и Саша рассуждаете в терминах "слил/не слил",
но не я, не ldv, не dottedmag@ и не raorn@. Не мы вели невнятный
разговор с подозрениями, недомолвками, утаиваемыми задачами и кодом. С
нашей стороны нет недоговоренностей, а вы говорите загадками. Или
считаем, что проехали, или потрудитесь объяснить проблему без всяких
недоговорок. Но не в этом списке рассылки, полагаю, -- мы и так
отвлекаем людей на совершенно непонятные (мне) и ненужные (мне)
разборки.

Rgrds, Алексей

> --
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>  ------ Linux.Kiev http://www.linux.kiev.ua/
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Michael Shigorin]

On Sat, Jan 17, 2009 at 07:41:16PM +0300, Aleksey Novodvorsky wrote:
> Михаил, поймите, это Вы и Саша рассуждаете в терминах "слил/не слил",
> но не я, не ldv, не dottedmag@ и не raorn@.

Это не так.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Бага ( формально ) может и нет , а вот проблема есть!

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Sat, Jan 17, 2009 at 04:30:01PM +0200, Michael Shigorin wrote:

MS> Здесь написано именно то, что написано: если хотите понять,
MS> почему развешивающие баги с патчами люди переходят в
MS> неконструктивную позицию -- почитайте их баги.

Все так. Однако:

1. Никто не запрещает форкнуть пакет. Очень редки ситуация когда его
форкнуть невозможно технически.

2. Если есть бага в багтрекере -- можно поднимать хай в devel@ и давить на
мантейнера. В том числе административными мерами, если это сотрудник ООО
или кого-то из партнеров.

Это не обязательно баг в багтрекере, но это обязательно -- некий документ
который четко и недвусмысленно описывает ситуацию.

>> Если да -- напишите в bugzilla,  пожалуйста.
MS> Я могу писать об этом в местное спортлото с тем же успехом, увы.

Неадекватное поведение одного человека не дает другому права на такое же.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]