Re: lug-bg: направи си сам RPM (беше:apache ili ...?)

[Petar Nedyalkov <bu@xxxxxxxxxx>]

On Wednesday 05 October 2005 13:19, Sava Chankov wrote:
> Petar Nedyalkov wrote:
> > On Wednesday 05 October 2005 11:52, Sava Chankov wrote:
> >> Petar Nedyalkov wrote:
> >>> On Wednesday 05 October 2005 10:43, Teodor Georgiev wrote:
> >>>> niama nujda da kompilirash "na ryka" vyv Fedora Core :)
> >>>> Gospod e dal SRPM (Source RPM).
> >>>
> >>> Има нужда. Особено ако знаеш точно какво искаш.
> >>>
> >>> Нали разбираш, че като излезе някоя нова версия на каквото и да е,
> >>> докато влезе в repository минава време, т.е. или трябва сам да си пиша
> >>> .spec, или да чакам и да редактирам .spec, премахвайки излишни неща или
> >>> слагайки липсващи такива, точно защото държа да ползвам оптимално
> >>> приложенията, а не всички "екстри" накуп.
> >>>
> >>> И си представи ако си правил тези операции много пъти, дали е по-лесно
> >>> да си ги компилираш на ръка, или да чакаш, или да губиш излишно време.
> >>
> >> Да инсталираш софтуер с make install на Fedora е горе-долу като да са
> >> купиш Майбах и да му смениш двигателя с двигател на Запорожец, щото
> >> последния се поддържа по-лесно - няма такива измишльотини като водно
> >> охлаждане например
> >>
> >> :)
> >
> > Въпроса е да има кой да ти го продаде този Майбах все пак. И ако ти
> > предлагат да ти докарат увас Голф 3ка (като примера по-доло с PHP 4.3),
> > мисля че ще предпочетеш да си идеш сам да си вземеш Майбах, нали?
> >
> > Ето например PHP 5 доста време не беше част от repository - хората си
> > разчитаха на 4.3 дълго време след като имаше PHP 5 - даже чак във Fedora
> > Core 4 има PHP5 (то е и разбираемо това с оглед разликите м/у двете
> > версии), а за FC3 последната актуална като гледам е 4.3.11 (а то има 4.4
> > branch вече). Аз пък случайни SRPM-та не съм "фен" да ползвам, още повече
> > пък RPM пакети от тоя и оня, затова и така съм постъпил - не съм си играл
> > да пиша .spec, не съм ползвал повече от една версия едновременно - не
> > мисля, че след като няма да го разпространявам като пакети, а говорим за
> > крайно стеснен брой deployments за вътрешни нужди, има смисъл да чакам от
> > Fedora да ми пуснат PHP5 пакет, или пък да съчинявам .spec.
>
> А защо просто не вземеш spec файла на PHP 4.3 от Федората - сменяш версията
> и опциите на configure, ако има добавени/изтрити файлове - отразяваш ги във
> %files и си готов? Това е най-лесния, бърз и праволинеен начин да се
> сдобиеш с пакета, който искаш.

Ами, как да ти кажа Сава, разликите м/у PHP4 и PHP5 не са малко, затова в този 
случай съм предпочел да си направя класиката в жанра и да действам бързо 
напред, а не да изолирам една по една опции дали ги има и в новата версия.

Примерно по xorg като пипам, в 99% от случаите минавам на разумния вариант да 
ползвам SRPM и да си го променя него. Ама пък на Fedora xorg пакетите си имат 
доста промени и като ми дотрябва да пусна на една машина две Matrox G450 с по 
четири video-outs (малко по специфична конфигурация) - еми предпочетох да си 
build-на xorg от source, да си сложа драйверите и HAL библиотеката на ръка, 
както и mga_vid т.н., вместо да trace-вам защо в оригиналните пакети към 
Fedora драйвера е пипан и не работи като хората или пък да преглеждам .spec 
файла, който не е като да е голям ;-)

По принцип си прав, но както казах и преди - в масовия случай това трябва да е 
практиката. Ама както даде пример с Майбах-а - той не е масов автомобил ;-)

>
> Специално за PHP мога да разкажа случай, в който се оправихме главно
> благодарение на пакетната система: колега инсталира уеб пощата hastymail,
> която обаче не тръгва и дава странни съобщения за грешка. Ама наистина
> странни. А сме я пускали 7-8 пъти на различни машини и наистина не
> разбираме защо така става. По едно време на мен ми хрумна да проверя целия
> софтуер, от който зависи hastymaiil. И какво се оказва - колегата
> инсталирал PHP за apache2, а ние сме с apache 1.3.

Ето тук си прав - по-бързо става с пакети.

>
> За случайните SRPM-та. Изходните пакети (SRPM) съдържат само:
> +) изходния код на програмата, който се инсталира в директорията SOURCES и
> спокойно можеш да презапишеш с  твоето копие, което си свалил от официалния
> сайт на проекта и си му проверил md5 сумата и подписа (ако има такъв). +)
> spec файл, който се инсталира в директорията SPECS
> +) евентуални кръпки, които се инсталират в директорията SOURCES и които в
> случай че се притесняваш можеш да изтриеш от spec файла
>
> Да не говорим, че повечето хора, които предоставят хранилища с RPM пакети
> (от основаните на RPM дистрибуции Федора е с най-много такива, на което
> искрено завиждам), го правят културно и ги подписват. На сайта на Весо
> Колев има много добро описание как се проверяват подписите на пакети.

Е, то някой ако не знае как се проверяват, лично моя съвет е да не се захваща 
с пакети въобще ами да ходи "Maximum RPM" поне да прочете, или пък `man rpm`, 
или на Весо Колев описанието.

>
> Тези неща не ги казвам, за да те разубедя да действаш както си знаеш.
> По-скоро искам да разсея митовете относно пакетните системи - че не са
> гъвкави и че са трудни за употреба - които за съжаление царят в милата ни
> Родина.

А-ха! Виж това лично мен ме изненадва, че съществува като мит (дори и да е 
само в Родината). Няма спор - имат си гъвкавост, не са трудни, в общия случай 
пестят много време и т.н. и т.н. - причини много.

Лично моят съвет е да се прибягва до нещата, които дадох като примери 
максимално рядко, но пък и не мисля, че някой ще отрече, че има случаи, в 
които времето, което се изисква са описване на spec файлове, dependencies и 
т.н., е много повече и може в конкретната ситуация да не си струва (примерно 
ако не целиш да правиш mass deployment пакет).

Та така. Мир и дружба :-)

-- 

Cyberly yours,
Petar Nedyalkov
Devoted Orbitel Fan :-)

PGP ID: 7AE45436
PGP Public Key: http://bu.orbitel.bg/pgp/bu.asc
PGP Fingerprint: 7923 8D52 B145 02E8 6F63 8BDA 2D3F 7C0B 7AE4 5436

Attachment: pgpkaK4Wem0qc.pgp
Description: PGP signature