Dotaz: Kompilace balíčku na jiném železe a přenos na slabší stroj

[Pavel David]

Mám starý počítač se slackwarem 10.1 tzn. kelnel 2.4 . Pc má malý disk. Na PC ve virtuálu si pro toto pc překládám balíčky na stejné verzi slackware, ale momentálně řešim problém, jak to na to staré železo nasypat.

Síť mi funguje, tzn. přenos souborů není problém, ale jde mi to, že když zkompiluji např. apache2 ./configure && make, co mám kam nakopírovat. Mám zkopírovat celý balík apache2 do /usr/local a pak dát make install a co pak mohu smazat.

Potřebuji vyřešit stávající stav a ne instalovat novější systém. PC je simens nixdorf scenic c5 .

Odpovědi

[Boris Michelsz]

Skúste pozrieť http://checkinstall.izto.org/index.php či by vyhovoval.

[Pat1]

Neslo by na silnem stroji namountovat root slabeho nekam do /mnt potom se do toho adresare chrootnout a pak uz klasicky prelozit a nainstalovat? Nikdy sem to neskousel, ale zajmalo by mne jestli to muze fungovat, skousel to nekdo? Dalsi vec je jak by to bylo rychly vzhledem k tomu ze by se vse tahalo po siti ...

[kai.101]

Toto mám vyzkoušené jen na Gentoo, ale mělo by to fungovat všude v případě, že binárky na cílovém stoji jsou zkompilované s podporou stroje, ze kterého se chrootuje a překlad je také cílen obecně (například i686) a nebo klidně přímo na cílový stroj ale ne na stoj, který kompiluje (tedy není tam např. gcc -marh=native nebo podobná autodetekce)

[oiufoj]

Jestli si dobre pamatuju, tak Slacware pouziva klasicke .tar.gz a mozna by mohlo stacit provest kompetni building do nejakeho nesystemoveho adresare a pak obsah zabalit a prenest. Asi takhle:

./configure --prefix=/tmp/usr/local
make install
tar zxf package.tgz usr/local -C /tmp

(nezkouseno)

Ocekavam, nejakou "Slackware policy", takze bude asi potreba dodat tam nejak ridici informace o tom aby system vedel o balickach. Asi by jsi se mel podivat na nejaky navod na vyrobu balicku pro Slacware.

[chochi]

Tak takhle bych to nedelal. Nastavit prefix znamena, ze si balicek mysli ze v te ceste bude nainstalovany. Tzn. ze pokud ma konfiguraky tak je bude cist z /tmp/usr/local/etc/konfigurak.
Spravna cesta (jak to napr. dela Gentoo a Exherbo pri jedne fazy instalace) je:

./configure
make
rm -Rf /tmp/install-root
mkdir /tmp/install-root
make DESTDIR=/tmp/install-root install
cd /tmp/install-root
tar cfvz ../balicek.tar.gz .

A na cilovem stroji

cd /
tar xfvz /spravna/cesta/balicek.tar.gz

Ted je ale otazka co udelat, aby sla oinstalace / upgrade. Asi nejednodussi bude si nechat balicek.tzr.gz a pri odinstalaci smazat vsechny soubory co v nem jsou a adresare, ktere po smazani zustanou prazdne (pres nejaky sikovny skript).

[rADOn]

ó nikoliv. Kdysi dávno na mindrákovi když jsem ještě byl pořádkumilovný jsem takhle kompiloval a instaloval kdečkové věci někam do $HOME odkud jsem je ručně kopíroval do /usr. A fungovalo to. Čestný pionýrský.

[l4m4]

Tak to byla asi nějaká vychytávka těch KDE-věcí.

[pavlix]

Kdysi dávno

Jen jestli tě paměť neklame.

někam do $HOME odkud jsem je ručně kopíroval do /usr.

Tak což o to, pokud jsi to pouze kopíroval a nemazal, tak to klidně mohlo běžet z části z /user a z části z /home.

[Ash]

Někdy vám to u něčeho jistě šlo, ale obecně to nefunguje, jak vám již bylo naznačeno, pokud informaci o prefixu použije konfigurák k jejímu využití třeba v konfiguračním souboru, tak pak pouhým kopírováním bez ztráty kytičky přesunout nejde. O DESTDIR naopak configure neví, takže to použít lze.

[lertimir]

Možná někde to fungovat může, ale obecně jistě ne. Jak už tady bylo zmíněno po kopírování to mohlo běžet částečně z nakopírovaného místa a částečně z původního.

Například configure apache s parametrem prefix tuto informaci jednak nakopíruje do make souborů a také po make install nakopíruje informaci do httpd.conf na lokace ServerRoot, DocumentRoot, ScriptAlias a do dost souborů v conf/extra informace o certifikátech, aliases, vhost atd. Všechno je to třeba přeeditovat při přesunu cílového místa.

[rADOn]

Mno co si tak pamatuju tak KDE3 měly na tohle proměnné v prostředí (KDEROOT nebo tak něco) takže asi když jsem tím zkopírováním zmrvil hardcodovany cesty tak si je to vzalo odtud. Určitě jsem to nikdy nedělal pro jiný než kdečkový aplikace. A už radši ani nebudu

[lertimir]

Zatím jsem podobný problém neřešil, ale pokud by tohle udržoval, asi bych měl ve virtuálu i na starším stroji přesně stejný systém a rsyncoval bych je proti sobě, řekněme s výjimkou jednoho podstromu, kde by byly právě zdrojáky a buildy. Neřešil bych, jak přenést, ale jak je mít stejné.

Pro starý systém by to na virtuálu nemuselo zabírat moc místa.

[MMMMMMMMM]

Osobně kompiluju většinu důležitých věcí, u kterých předpokládám pravidelné aktualizace (php, apache, mysql), s prefixem, např. ./configure --prefix=/usr/local/httpd-2.4.1

Když pak provedu make a make install, mohl bych sbalit adresář /usr/local/httpd-2.4.1 a rozbalit jej na pomalejším (co do softwarové výbavy identickém) stroji - to by mělo fungovat, ne? Samozřejmě díky prefixu je dobré do systémové proměnné PATH hodit cestu k vytvořeným binárkám (/usr/local/httpd-2.4.1/bin).

[Ash]

Pokud instalaci provozujete pod stejným prefixem jako jste ji konfiguroval, tak to samozřejmě fungovat bude. Kritika výše se týkala možnosti konfigurovat někam do tmp, a pak provozovat v /usr, to může ale nemusí fungovat.

[viva]

Myslím, že by bylo rozumné zkusit upravit si Slackbuild skript - na SlackBuilds.org je k dispozici apache2 pro Slackware 11