rpm 5.1

[Володимир Лісівка]

Вийшла перша стабільна версія нової гілки RPM Package Manager. На відміну від RPMv4, розробка якого контролюється RedHat, RPMv5 розробляється окремою незалежною групою розробників.

Розробники повідомили, що на їхню думку RPMv5 є достатньо добре відтестований і придатний для використання в дистрибутивах. Зокрема, RPMv5 був скомпільований на всіх доступних розробникам компіляторах і операційних системах, а також був зібраний і проінстальований реальний дистрибутив на платформах Linux та BSD. Зворотня сумісність з RPMv4 підтримується, тоді як підтримка RPMv3 (яка вимагається LSB) викинута.

Найбільш цікава зміна в новій версії - це можливість писати скрипти на LUA.

Оголошення: http://rpm5.org/community/rpm-users/0190.html

[Володимир Лісівка]

Знову - кожній програмі свою мову програмування.   Ну чому не можна було використати JavaScript, Python, чи perl - три найвідоміші мови програмування для Лінукс?

[Cthulhu]

Знову - кожній програмі свою мову програмування.   Ну чому не можна було використати JavaScript, Python, чи perl - три найвідоміші мови програмування для Лінукс?

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

За прикладами надзвичайно успішних проектів, реалізованих таким чином далеко ходити не треба: emacs і sawfish зі своїми діалектами lisp, vim, zsh зі своїми підходами... врешті, навіть ff з XUL.

Хоча якщо ви маєте на увазі використання якоїсь дикої екзотики для таких цілей, без модифікацій в початковій імплементації - тут я міг би погодитись.

[Володимир Лісівка]

Знову - кожній програмі свою мову програмування.   Ну чому не можна було використати JavaScript, Python, чи perl - три найвідоміші мови програмування для Лінукс?

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

За прикладами надзвичайно успішних проектів, реалізованих таким чином далеко ходити не треба: emacs і sawfish зі своїми діалектами lisp,

Колись не було common lisp, тому існували тільки діалекти lisp.  :-) Але добре що автори не стали придумувати щось своє, тому ці проекти живі до сих пір.

vim, zsh зі своїми підходами...

З мовою vim не знайомий, але було б краще для проекту, якби там використовувалося щось стандартне. Є купа успішних проектів з купою плагінів, які нової мови не придумували, починаючи з Multi Edit, наприклад, і закінчуючи Eclipse.

врешті, навіть ff з XUL.

Мозіла/FF/TB використовують XUL для графіки (XML-based User interface Language), це те саме що плутати .glade з .py. Для написання розширень вони використовують JavaScript.

[Cthulhu]

Колись не було common lisp, тому існували тільки діалекти lisp.  :-) Але добре що автори не стали придумувати щось своє, тому ці проекти живі до сих пір.

Угу. Але про те і мова - в обох випадках маємо справу з модифікаціями того ж ліспа. Не думаю, що вони були б менш успішними, якби придумали щось взагалі своє.

З мовою vim не знайомий, але було б краще для проекту, якби там використовувалося щось стандартне. Є купа успішних проектів з купою плагінів, які нової мови не придумували, починаючи з Multi Edit, наприклад, і закінчуючи Eclipse.

Але ж на успіх проекту це ніяк не вплинуло, правда? Vim реклами не потребує. Мова його достатньо нескладна, і ідеально підходить поставленим задачам. Можна навіть поставити питання так: чи не завдячує проект своєму успіху використанню своєї мови?

Мозіла/FF/TB використовують XUL для графіки (XML-based User interface Language), це те саме що плутати .glade з .py. Для написання розширень вони використовують JavaScript.

Я знаю, навіть сам трошки писав... власне, в схему це вкладається - діалект популярної мови для специфічного класу задач.

Власне, не про те мова. Що було б зі згаданими проектами, якби вони вибрали інший підхід - ніхто не знає=) Працюють вони, і добре. Мова про те, чи виправдає себе такий підхід в rpm? Я оце от трошки про те LUA почитав. Ніби нічого така штука. Думаю, толк з того буде і rpm-у це аж ніяк не зашкодить. Хоча причин для вибору саме LUA я не поки не побачив. Взяли б той же лісп, взагалі було б круто.

[Володимир Лісівка]

Колись не було common lisp, тому існували тільки діалекти lisp.  :-) Але добре що автори не стали придумувати щось своє, тому ці проекти живі до сих пір.

Угу. Але про те і мова - в обох випадках маємо справу з модифікаціями того ж ліспа. Не думаю, що вони були б менш успішними, якби придумали щось взагалі своє.

Приклади тих проектів, які не дожили до цього часу, показують що могли б. Якби не lisp, Emacs не став би таким комбайном. :-)

З мовою vim не знайомий, але було б краще для проекту, якби там використовувалося щось стандартне. Є купа успішних проектів з купою плагінів, які нової мови не придумували, починаючи з Multi Edit, наприклад, і закінчуючи Eclipse.

Але ж на успіх проекту це ніяк не вплинуло, правда? Vim реклами не потребує. Мова його достатньо нескладна, і ідеально підходить поставленим задачам. Можна навіть поставити питання так: чи не завдячує проект своєму успіху використанню своєї мови?

Мова віму достатньо обрізана, що заважає написати до нього достатньо корисні інструменти, через що він й досі залишається текстовим редактором, на відміну від Emacs. :-/

Власне, не про те мова. Що було б зі згаданими проектами, якби вони вибрали інший підхід - ніхто не знає=) Працюють вони, і добре. Мова про те, чи виправдає себе такий підхід в rpm? Я оце от трошки про те LUA почитав. Ніби нічого така штука. Думаю, толк з того буде і rpm-у це аж ніяк не зашкодить. Хоча причин для вибору саме LUA я не поки не побачив. Взяли б той же лісп, взагалі було б круто.

Ну і я про те саме. Хоча зараз perl і python можна використовувати для написання зовнішніх (відносно RPM) скриптів (той же ж yum чи smart, як приклади). Напевно автори забоялися робити залежності на повномаштабні мови, тому вибрали маленьку LUA. Об’єктно-орієнтовані мови (такі як JavaScript) їм не підходили напевно в принципі через не-ООД самого RPM та через складність інтеграції.

Коротше, я змінюю гнів на милість: Lua була правильним вибором.  

[Cthulhu]

Приклади тих проектів, які не дожили до цього часу, показують що могли б. Якби не lisp, Emacs не став би таким комбайном. :-)

Мова віму достатньо обрізана, що заважає написати до нього достатньо корисні інструменти, через що він й досі залишається текстовим редактором, на відміну від Emacs. :-/

Можливо, я не труЪ, але надаю перевагу stand-alone кавоваркам=)

Ну і я про те саме. Хоча зараз perl і python можна використовувати для написання зовнішніх (відносно RPM) скриптів (той же ж yum чи smart, як приклади).

Та й не тільки. Дуже багато хто так робить.

Напевно автори забоялися робити залежності на повномаштабні мови, тому вибрали маленьку LUA. Об’єктно-орієнтовані мови (такі як JavaScript) їм не підходили напевно в принципі через не-ООД самого RPM та через складність інтеграції.

Коротше, я змінюю гнів на милість: Lua була правильним вибором.

Напевне. Хоча хтось знає дистрибутив без перла і пітона з коробки?

На жаль, толком з lua не знайомий... але хороший привід.

[Praporshic]

Хоча хтось знає дистрибутив без перла і пітона з коробки?

LFS?

[Володимир Лісівка]

Напевне. Хоча хтось знає дистрибутив без перла і пітона з коробки?

Моя мобілка йшла без perl чи python в комплекті. Зі скриптових мов - тільки shell (навіть не bash).

[Praporshic]

Моя мобілка йшла без perl чи python в комплекті. Зі скриптових мов - тільки shell (навіть не bash).

От тільки RPM`ом там і не пахне. Воно ближче до dpkg

[Cthulhu]

Напевне. Хоча хтось знає дистрибутив без перла і пітона з коробки?

Моя мобілка йшла без perl чи python в комплекті. Зі скриптових мов - тільки shell (навіть не bash).

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

Хоча хтось знає дистрибутив без перла і пітона з коробки?

LFS?

Там з черепної коробки.

[Михайло Даниленко]

А я нещодавно як налаштовував ion - вивчив-таки lua. :-P
Враження - сильно порізаний перл. Принаймні реалізація класів/об'єктів у них дуже схожа.

А у LFS perl іде у базовій системі - він потрібен для збирання деяких пакунків.

[Praporshic]

А у LFS perl іде у базовій системі - він потрібен для збирання деяких пакунків.

Але пістону там немає. Логічна конструкція "and" повернула false

[Володимир Лісівка]

Моя мобілка йшла без perl чи python в комплекті. Зі скриптових мов - тільки shell (навіть не bash).

От тільки RPM`ом там і не пахне. Воно ближче до dpkg

Там використовуються пакети mpkg - звичайні .tgz архіви. Проект mkezx пакує ПЗ у .deb-и, і дає можливість встановлювати їх apt-ом. Точнісінько так само можна пакувати ті самі пакети в .rpm і встановлювати yum-ом (чи apt4rpm), але на відміну від apt-а, yum-у потрібен пітон, так що yum краще запускати за межами мобілки. :-)

[gvy]

Ну чому не можна було використати JavaScript, Python, чи perl - три найвідоміші мови програмування для Лінукс?

Якщо б ти був не розробником на цих еее... мовах, а пакаджером, то дуже швидко б зрозумів.  Особливо про пєтон.

Для JS/EcmaScript досі немає нормальної _бібліотеки_ з двигуном (й не треба мені казати про SpiderMonkey та WebKit), перл -- ти пропонуєш напівмертвий 5 чи неживий 6?, а щодо серпентарію -- яку з несумісних підверсій тягнути в системно-критичну тулзу?

То ембеднута мова тут набагато краще, а lua достатньо.

PS:
> Колись не було common lisp, тому існували тільки діалекти lisp. [...]
CL -- такий само діалект lisp, як й Emacs Lisp

> Якби не lisp, Emacs не став би таким комбайном.
emacs -- це власне lisp-машина (почитай про Symbolics).

> через що він й досі залишається текстовим редактором
За що й цінуємо -- два (ну... вже півтора) emacs є, чи то недостатньо?

> Хоча зараз perl і python можна використовувати для написання зовнішніх
> (відносно RPM) скриптів
Можна й для %post, бо й інтерпретатор регулюється, й here doc не відміняли.