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
pgpBb2ZJs7dxt.pgp
Description: PGP signature
