[devel] Поддержка проприетарщины в Sisyphus

[Алексей Любимов]

>> Поставьте себя на место девелопера. Невозможно собирать пакеты для 
>> всех. Должны быть какое то ограниченое количество стандартов а уж 
>> остальным придется как то поддерживать совместимость.
>
>
> Да. К сожалению, LSB скорее мертв, чем жив.
>
ну так из этих сожалений должны быть выводы.
осторожней надо плодить несовместимости и оглядываться на лидеров рынка, 
даже если они чего то делают "не в струю".

>> Система проведения изменений в альт неприемлима для хоть сколько 
>> нибудь серьезных заказчиков. Серьезные заказчики в данном контексте, 
>> это все, кто хочет при любых обстоятельствах сохранять наработанное, 
>> готов добавлять свое и готов осваивать чужое, а не поставить и 
>> тыкаться по виджетам. Здесь уже было много истерик по поводу 
>> невозможности такой работы с альтом.
>
>
> От серьезных заказчиков?

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

>> И во всех случаях присутствовала доля правды. Отсылки в платную 
>> поддержку решений ничего не доказывают. Еси в альте плюют на всех 
>> неальтовцев (свободных и не очень) в основном дереве,
>
>
> Вот здесь -- подробнее, пожалуйста.
>
Где селеты спеков? Где документированные процедуры "как надо" по всем 
альт-зависимым вещам? Где забота о сборке сторонних приложений? Вам не 
нужны la - нет проблем. Оставьте из в devel-static и не ставьте их на 
время сборки - никто же слова не скажет. Нет, прибили все static да еще 
и в static все *.la вычистили. В итоге сборка статического пакета 
выливается в пересборку всех зависимостей с --enable-static и правкой 
спеков. Это называется нежная забота о сторонних пакетах и пользователях 
оных?  Или это все борьба с проприетарщиной?

Прямо на atmsk/linux-os выкладывать такую информацию  некошерно, 
понимаю. А где это делается? И стоит ли после этого удивляться ругани в 
форумах на "глючность" альта. Никто ведь не обязан разглядывать 
config.log а далее макросы в /usr/lib/rpm чтобы понять, почему то, что 
собирается у всех без вопросов у нас стоит как вкопаное...

> На самом деле, в этом менющемся мире надо искать свою нишу.

Это уже вопрос внутрифирменый. Достаточно поставить в известность всех 
остальных о том,где же вы нашли свою нишу. Пока, вроде, везде. :)

> Дистрибутив, поддерживающий проприетарщину -- ниша. Она будет 
> стремительно сокращаться. И даже если мы в нее просунем ногу -- завтра 
> нас оттуда выкинут. Здесь надо хладнокровно считать, чего я пока не 
> наблюдаю. Думайте о завтрашнем и послезавтрашнем дне, а не только о 
> сегодняшнем.

Да чего вы зациклились на проприетарщине? Опенофис от зимиан, который я 
не в состоянии собрать, эта таже "проприетарщина". Есть же уже собраный 
под редхат, зачем его пересобирать? И таких пакетов много. А еще больше 
тех, которые не собираются из за "особенностей" сборки тех пакетов, на 
которые они опираются или просто из за "особенностей".

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

Я б сказал, один язык и одни проблемы. Поддержка из за океана _вообще_ 
обычно лучше.

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

>>
>> А никто не говорит о "поддержке". Поддержка, это неправильное слово. 
>> Речь то идет о совместимости. А если этой совместимости нет в сизифе, 
>> то откуда она появится в дистрах? Еее же никто не проверял в то 
>> время, когда это надо было делать - в сизифе.
>
>
> Ok. Давайте рассмотрим, каков может быть механизм такой проверки.

Никакая проверка ничего не даст. Надо вносить изменения в процесс 
девелопмента сизифа. В нем, в этом метании и волюнтаризме вся 
несовместимость.

Несовместимости возникают по нескольким причинам.

1) несовместимы версии библиотек
2) несовместимости внесеные в ядро или библиотеки патчами типа owl
3) несовместимости внесеные разными установками по умолчанию (например, 
лимиты в ядре или blowfish или tcb в паролях)
4) несовместимости внесеные реализацией - чруты, конфиги etc

В процессе девелопмента постоянно возникают те или иные побуждения - 
отправить пинг в чрут, перевести cups под юзера, перепотрошить сборку 
постфикса, раздраконить питон, внедрить tcb, наложить owl на *std-up ядро.
Почему бы прежде чем вносить такие изменения не проанонсировать их, не 
ответить на вопросы по тем или иным ситуациям, затем по результатм 
обсужждения принять решение о применимости этих изменений, затем 
задокументировать эти изменения и опубликовать вместе с рецептами 
решений возможных проблем и только потом прикладывать патчи? Такая 
процедура сняла бы тонну вопросов и несовместимостей...

Ну и определиться с пределами своей компетенции. Разрезаный cups и 
blowfish по умолчанию явно эти пределы перешагнули.

А механизм проверок уже есть. Багзилу никто не отменял.

>
> Хм. Не ко всякому из "народа" я хочу поворачиваться лицом. Да и "без 
> меня народ не полный".
> Давайте все же сюда конкретику.
>
> Rgrds, Алексей
>
Вроде привнес.