[BugFixed]
Отслеживание ошибок
| Author |
Message |
|
Written on: 12. 11. 2009 [12:16]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
А правка configure.in не помогает?
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Written on: 12. 11. 2009 [12:18]
|
|
Aleksey
Aleksey Popkov
Contributor
registered since: 31.07.2008
Posts: 326
|
Fedora release 11 (Leonidas)
automake17-1.7.9-12.noarch
automake16-1.6.3-15.noarch
autoconf-2.63-2.fc11.noarch
automake14-1.4p6-18.fc11.noarch
automake-1.11-2.fc11.noarch
automake15-1.5-26.noarch
libtool-2.2.6-11.fc11.1.x86_64
Весь комплект )))))))
[This article was edited 1 times, at last 12.11.2009 at 12:19.]
|
|
Written on: 12. 11. 2009 [12:27]
|
|
kuzulis
Денис Шиенков
registered since: 10.07.2009
Posts: 128
|
А правка configure.in не помогает?
Еще не знаю, отпишусь как приду домой. т.е. после 18:00 по Москве 
|
|
Written on: 12. 11. 2009 [12:28]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
AltLinux 5.0
autoconf_2.60-2.63-alt4.noarch
autoconf-common-0.3-alt1.noarch
automake_1.11-1.11-alt2.noarch
automake-common-0.3-alt1.noarch
libtool_2.2-2.2.6-alt10.i586
libtool-common-0.2-alt3.i586
PS Уже плавно перешел
[This article was edited 1 times, at last 12.11.2009 at 12:47.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Written on: 12. 11. 2009 [21:26]
|
|
Aleksey
Aleksey Popkov
Contributor
registered since: 31.07.2008
Posts: 326
|
И, кстати, Алмаз, по поводу разных дистрах. Хорошо когда на различных дистрах люди пытаются тестить, потому как есть 2-ва примера когда это оказалось не лишним. (Может примеров и больше)
1. При сборке на Fedora x86_64 была бага с поиском libmysqlclient.so файла, и в результате, при сборке с поддержкой MySQL сборка обламывалась на моменте поиска этого файла. Приходилось копировать в /usr/lib/mysql этот файл. Позже был прикручен макрос который при сборке ищет этот файл по перечисленным в макросе путям.
На Alt ничего такого не происходило. Таже проблема наблюдалась и с FireBird.
2. Также когда в Fedora, оно довольно часто обновляется(из перечисленных нами версий пакетов это наглядно видно), появился openssl-devel новый, OpenSCADA Роман тоже запилил, потому как не собиралась и опять же на Alt все было нормально. Появилась в Alt этот openssl-devel сейчас, я не знаю, но благодаря тому что когда-то это было выявлено на Fedora, проблема была быстро решена.
Мало того, в процессе внедрения OpenSCADA в репозитарии Fedora, выявилась бага rpm-build, rpm не правильно обрабатывает макрос error в spec файле, и самое интересное, что за 10 лет существования этой баги, никто не обращался по этому поводу.
(Это сказал сам разработчик RPM Jeff Johnson )
https://bugzilla.redhat.com/show_bug.cgi?id=528663
И в CentOs не было portaudio, пришлось его туда добавить.Теперь обладатели CentOs получили возможность использовать DAQ.Sound ))))
Как видно из приведенного выше, не только улучьшаем OpenSCADA, но и в дистрах делаем добавления и вносим поправки )))))
[This article was edited 4 times, at last 12.11.2009 at 21:41.]
|
|
Written on: 13. 11. 2009 [00:25]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
Все эти примеры по сути одно и то же - устранение ошибок дистрибутивов, которых не счесть (и дистрибутивов, и ошибок).
Тут надо правильно расставить цели и приоритеты.
Приоритеты:
Считаю развитие отдельно взятых программ (ядро, кде, опенскада и тд) более важным, чем развитие целого дистрибутива, так как это всего лишь сборки программ. По роду своей деятельности нам нужна OpenSCADA.
То есть ставим развитие OpenSCADA выше развития любого дистрибутива. Соответственно, тестить, устранять ошибки и использовать надо OpenSCADA, а не что-то другое.
Цели (начиная с самой важной):
1. Автоматизация объектов наиболее надежным, экономичным, универсальным, открытым и эффективным способом (исходя из такой цели была создана OpenSCADA)
2. Выбор программы для достижения 1 цели (выбрана OpenSCADA)
3. Выбор окружения для OpenSCADA (то есть дистрибутива linux), в котором она будет лучше всего работать.
ну и далее много пунктов среди которых есть устранение ошибок дистрибутивов
Может быть я это неправильно для себя расставил?
Денис, вот Вам что важнее? Запустить, наконец, OpenSCADA и начать с ней работать или устранить ошибки Arch?
PS Нисколько не умаляю роль дистрибутивов. Естественно цели дистрибутивостроителя будут отличаться от моих.
[This article was edited 2 times, at last 13.11.2009 at 00:43.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Written on: 13. 11. 2009 [07:47]
|
|
kuzulis
Денис Шиенков
registered since: 10.07.2009
Posts: 128
|
Денис, вот Вам что важнее? Запустить, наконец, OpenSCADA и начать с ней работать или устранить ошибки Arch?
1. Запустить OpenScada + создть для неё PKGBUILD, чтобы другие тоже могли в Арче её пускать.
2. Я не считаю, что это проблема Арча, т.к. скорее всего эта новая "фича" в утилитах типа "develop" ориентированных, которая заключается в изменении синтаксиса и нюансах парсинга и генерации скриптов и т.п. Просто, скорее всего, девелоперы OScada пропустили что-то очень важное , т.к. другие приложения (все что я ни собирал) - собираются без каких-либо ошибок.
ИМХО, говорить, что это ошибки в дистрибутиве - это немного"голословное" уверждение, т.к. дистрибутив тестят уж больше чем 7 человек
Также не понимаю, почему автор OScada так "кипятится" по поводу того, что у него все работает а у меня нет?!
Это же нормально, что у кого-то на другой платформе (дистре) есть иные нюансы, поэтому, считаю, нужно исправить в OScada эти моменты, т.е. адаптировать ее под наибольшее кол-во дистрибутивов.
ЗЫ:
ошибки при сборке (другого рода) вываливались также у меня ранее с OScada , когда я использовал слакварские дистры типа:
- самой слаки
- мопса
ЗЫЗЫ: я не хочу и не буду у себя ставить rpm - базед дистрибутивы, т.к. мне они не нравятся и они "кривые".
ЗЫЗЫЗЫ: Вам кажется, что это ошибки в Арче - а мне кажется, что это ошибки в Альте и Федоре (т.к. эти дистры - "ягодки с одного и того-же поля")
[This article was edited 1 times, at last 13.11.2009 at 07:50.]
|
|
Written on: 13. 11. 2009 [08:40]
|
|
Aleksey
Aleksey Popkov
Contributor
registered since: 31.07.2008
Posts: 326
|
О ошибках в дистрах и приоритетах можно рассуждать долго и бесполезно, потому как для каждого они свои. Ничего плохого в том, что собирая OpenSCADA, поправят что-то в дистре. Предусмотреть все, весьма трудно. Если замечена ошибка, почему-бы о ней и не сообщить разработчику. А ошибка OpenSCADA или какого-нить пакета не столь важно, рассуждать как потребителю конечно легче, но почему бы не внести свою лепту в улучьшение ? И опять же, какая разница в улучьшение чего OpenSCADA, RPM или какого-нить другого пакета.
По поводу использования RPM, на вкус и цвет товарищей нет, менеджеров пакетов много.
Кому больше нравиться какая-нить другая скада система, не используют OpenSCADA, и при этом доказывать, что тем чем они пользуются, пользоваться по каким-то причинам аморально, тоже не вижу смысла. Ну нравиться нечто другое и ладно, тут народ сидит на OpenSCADA, на других форумах народ обсуждает другую тематику.
И когда речь заходит о правке дистра какого-нить, по сути пакеты или пакет пилить начинают.
Дистр на котором OpenSCADA лучьше работает или хуже, об этом судить пока что рано, так как этой статистики никто не вел, хотя и интересно конечно.
[This article was edited 2 times, at last 13.11.2009 at 08:44.]
|
|
Written on: 13. 11. 2009 [13:16]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
Почему же долго и бесполезно? Любые рассуждения должны приводить к каким-то выводам.
Одно время я перепробовал множество дистрибутивов Linux, пытаясь что-то выбрать, и кое-какие выводы для себя сделал. Приведу их здесь - может кому помогут определиться в этом вопросе.
Дистрибутив - сборка программ воедино по определенным правилам (законам). Если исходить из пословицы "на вкус и цвет ..." то у каждого эти правила (законы) свои.
В связи с этим развитие дистрибутивостроения происходит аналогично развитию человеческого общества: племена - общины - княжества(королевства) - государства - союзы государств - мировое сообщество.
Когда-то у каждого был свой дистрибутив (этап давно пройден), потом на сотню-тысячу людей свой дистрибутив (этап пройден), сейчас свой дистрибутив на каждый континент или государство (нынешнее время, основных популярных дистрибутивов несколько десятков, может сотен).
В недалеком будущем должны быть разработаны стандартные правила (законы) дистрибутивостроения, приемлемые для всего человечества. Может они уже есть. Если эти стандарты выдвинет авторитетная организация свободного сообщества и мир за ними потянется, это приведет к появлению единого мирового дистрибутива (ну может с несколькими ветками по видам деятельности или др.)
В настоящее время для стран бссср оптимальным дистрибутивом является AltLinux. А скорее единственным. Не надо забывать на каком участке планеты живем.
Теперь взглянем на это с точки зрения разработчика OpenSource программы. В случае единого мирового дистрибутива как было бы ему удобно разрабатывать, соответственно он бы сосредоточился на самой программе, а не на доведении ее до различных окружений. Качество программы бы увеличилось, время разработки бы сократилось.
А как же происходит в настоящее время?
Разработчик выбирает один дистрибутив из множества (неважно чем он руководствуется при выборе) и создает в нем нужную программу. Соответственно программа получается заточенной под этот дистрибутив и именно в нем она работает наиболее надежно. Далее по просьбе пользователей он может приспособить ее к другому дистрибутиву, уделив при этом минимум времени, так как ему это не особо нужно. Программу может откомпилировать-приспособить вообще не разработчик, а майнтейнер дистрибутива. В другом дистрибутиве при работе этой программы появляются баги, которых нет в первом дистрибутиве.
В итоге имеем множество OpenSource программ и каждая в каком-то дистрибутиве хорошо работает, в каком-то не очень, в каком-то отвратительно, в каком-то вообще никак.
Так как дистрибутивы на 95% состоят из одних и тех составляющих (правда собранных по различным правилам различными людьми), дистрибутивы выглядят более-менее хорошо. Но когда начинаешь устанавливать и разбираться с ними всё не так радужно.
Вывод: узнай на каком дистрибутиве разрабатывалась твоя любимая программа и она тебе понравится еще больше.
Насчет потребительского подхода.
1. Самый потребительский подход: сказал, что тебе нужно, заплатил, сделали. Не важно на кой ОС, в какой программе и тд. Это чаще конечные потребители.
2. Рационально-потребительский подход. Скачал OpenSource программу. Установил. Что-то не получилось. Сообщил. Помогли. Разработали. Все получилось. Это внедренцы.
3. Мой подход. Скачал программу. Установил. Чего-то не хватило. Разработал. Проверил. Поделился с сообществом. Чего-то не смог разработать. Попросил. Все получилось.
Пилить под кучу дистрибутивов не вижу особого смысла (может только под 2-3 распространенных дистрибутива). Лучше пополнить код проекта.
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Written on: 13. 11. 2009 [14:08]
|
|
Aleksey
Aleksey Popkov
Contributor
registered since: 31.07.2008
Posts: 326
|
С некоторыми высказываниями не согласен.
Сравнение: Не производят автомобильные шины, только для определенного автомобиля. Ну если это не карьерный самосвал. Как правило одни и теже можно поставить на разные автомобили.
Linux - машина
OpenSCADA - шина
Но дабы закончить с флудом на эту тему, не буду рассуждать.
Пускай мое слово не будет последним 
[This article was edited 3 times, at last 13.11.2009 at 14:14.]
|
|
|
