[Megoldva] Debian Etch vs Testing?

Debian GNU/Linux

Sziasztok.

Debian Etch rendszerem van és fontos a stabilitás a munka gépemen. Viszont van egy-két alkalmazás, amelyeknél szükségem lenne a frisebb verziókra (ilyen pl. a tegnap megjelent Gimp 2.4-es verziója).

Persze Debian csomag még nem érhető el (nem is lesz gondolom Etch-hez). Forrásból fordítanám le, de kell neki az újabb GTK+ >= 2.10, ami ugye az Etch-ben régi = 2.8.

Kérdésem, hogy van-e arra valami megoldás, hogy továbbra is a stabil Etch-et használjam, és néhány programot le tudjak fordítani azok közül (vagy használni tudjak), amelyeknek kell a frisebb GTK? Milyen egyéb megoldás létezhet?

Vagy pedig mi a tapasztalat a Testing-gel? Mennyire bug-os? Meg tudtommal nincs hozzá biztonsági frissítés.

Előre is köszi minden véleményt!

  • 2846 megtekintés

( utpKabel | 2007. 10. 25., cs – 22:26 )

Meg tudtommal nincs hozzá biztonsági frissítés.
Ezt nem jól tudod.

Én egyszer már próbáltam újabb GTK-t fordítani, de az problémás, mert az etch csomagok a régi GTK-val lettek lefordítva.

Valahol rémlett hogy olvastam, hogy nincs biztonsági frissítés (legalábbis nagymértékben), de aztán megtaláltam:

Please note that security updates for testing distribution are not managed by the security team. Hence, testing does not get security updates in a timely manner.
http://www.debian.org/releases/testing/

De köszi az infót, nem fogok akkor GTK-t fordítani.

( pinyo_villany | 2007. 10. 25., cs – 22:30 )

chroot-ban kialakítasz neki egy kis saját "rendszert", igaz ez sok hellyel jár, de szerintem működik ...

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.
debian 4.0 - linux-2.6.22.10-pancs1-wifi2 - 2.6.22.9 kernel madwifivel itt

Idézet: "chroot-ban kialakítasz neki egy kis saját "rendszert", igaz ez sok hellyel jár, de szerintem működik ..."

Akkor le is lehetne talán script-ezni, hogy mondjuk az új GIMP indúljon, igaz?

Tehát a scriptben: --> chroot --> aztán gimp?

A chroot környezetbe tulajdonképpen az egész rendszert le kellene mégegyszer másolnom és dist-upgrade-elnem?

létrehozol 1 mappát, bechroot-olsz, majd debootstrap-al felhúzod az alap debian file-okat ( azt a verziót ami neked tetszik ), majd azon belül még apt-get-el felpakolod ami neked kell ( jelen esetben gimp )..
Miután mindennel végeztél kell egy script ami ezek után auto bechroot-ol az adott mappa alá, majd elindítja a progit ( a progi ilyenkor minden beállítását/függőségét a chroot-ban fogja keresni ), és lényegében így egyfajta jail-t alakítasz ki neki, aminek a legnagyob belőnye, hogy lehet a főOS-ed mondjuk testing ( lenny ), addig a debootstrap-ban lévő akár stable is ( vagy fordítva, ahogy tetszik ).
Mindeközben egyáltalán nem használsz virtualizációt, és a sebességed se esik vissza ( teljesen natívan megy minden ), csupán kicsit több hely kell, hogy felhúzz fil szinten a chroot-ban egy újabb debian-t.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

( gabim | 2007. 10. 26., p – 10:17 )

Nem kell forrásból fordítani, nem kell chroot-os rendszer, sem virtuális gép.
A megoldás az apt pinning, amivel kevert rendszert hozhatsz létre, a Debian különböző verzióinak keverésével.
Röviden: http://jaqque.sbih.org/kplug/apt-pinning.html
A hivatalos howto szerint: http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html
És egy fórumban leírva, tapasztalatokkal: http://forums.debian.net/viewtopic.php?t=15612

LOL.... Kipróbáltam a pinninget... soha-soha többé... Aki kitalálta simán csak fel kellene akasztani. Hogy mennyire összekavarta a rendszert a tutorial saját beállítása...
Elképesztő... És tudod mit szerettem volna csak? Egy nyamvadt 6-os jdk-t felrakni egy etch-re! És nem-nem, mert minden szar java-related dolgot upgradelni akart, hogy most akkor ő talán ezt itt és most. És utána persze a tomcat sírt, az utólag telepítendő dolgok sírtak... Gentoo alatt ezt miért lehet egy emerge ">=sun-jdk-1.6" paranccsal elrendezni? Talán a Gentoo-sok okosabbak lennének? Nem tudom, és nem is érdekel. Btw, SuSE alatt sem kell ennyit szopni a 6-os javáért. Tudom, tudom, sh jdk-1.6*.bin, de az eléggé gány megoldás. Szerintem.

Igen? És a tomcat-nek hogy mondod meg, hogy akkor most nem ez a java hanem az?
Másfelől én szeretem, ha a rendszerhez tartozó fájlokat a csomagkezelő kezeli, vagy legalábbis tud róluk.
Kényelmetlenül érzem magam, ha valamit "forrásból", azaz nem az adott rendszer csomagkezelőjével kell feltegyek. Arról már nem is beszélve, hogy mi van akkor, ha valami olyan csomagom van, ami java 6-ot igényel? Hogyan mondod meg Debian alatt, hogy kedves, ez már telepítve vagyon. Tudom, disable dependency check. Csak ez megint annyira nem szép megoldás, annyira meg kell erőszakolni a rendszert...
Ez rossz, amelyik rendszernél ilyesmire van szükség, ott bizony bajok vannak, és ennél sokkal nagyobb bajok, ez már csak a betegség egyik tünete.

A java-package metódusról is tudok ám, de itt elsősorban az apt pinning hiányosságaira szerettem volna felhívni a figyelmet, nem pedig a java problémára.
Btw: Ha már valamit az abszolút unstable ágból kell feltenni, az nem frusztrál amúgy senkit egy kicsit sem? Hogy ennyire kerülő úton kell valamit megoldani, az sem? Szerintem ott igenis bajok vannak, ahol ennyit kell hekkelni egy amúgy agyonreklámozott dolog miatt... (hoyg annó mekkora felhajtás volt aból, hogy lehet végre csomagos java-t csinálni rendszerek alá... aha, persze), független attól, hogy a dolgot meg lehet-e oldani vagy sem.
Egy nálam kevéssé jártas felhasználó számára ez kész gyötrelem, amikor már kicsavarodott testtel kell kecskét áldozni keresztútnál nyári éjjel hogy a dolog működjön.
Igen, hát nem véletlen nem ajánlják a Debian-t kezdőknek...

Én egy éve Debian-nal kezdtem totál kezdőként :DDDD

hát mit ne mondjak, volt egy kis győtrelmem --> xorg konfigurálás --> alsa beállítása --> raid1 beüzemelése --> csomag kezelővel trükközések stb stb. Windows-ról jövet a 2 klikkes dolgokhoz képest "más" volt... de megérte!! (és működött)
Jó nagyokat szívtam (meg sokat gugliztam), de legalább megtanulom :DDD

Az alap problémát szerintem az jelenti, hogy ki dönti el, hogy mi stabil. Gondolom ha a szoftver valamelyik verzióját a fejlesztők stabilnak nyilvánítják, akkor az még jó ideig nem kerül bele a stabil repo-ba, mert a csomag-karbantartók is teszt alá veszik, igaz?

Szerintem a rendszer magján kívül nyugodtan frissíthetnék a felhasználó alkalmazásokat gyakrabban a stabil repo-ban. Elvégre attól még nem lesz stabilabb, ha 1 év múlva teszik bele, hanem addig is nem elérhető. És a rendszer magot tarthatnák altatva stabilan, csak biztonsági frissítésekkel.

De lehet hogy rosszul látom a dolgot, javítsanak ki a tapasztaltak.

Nekem a problémát az jelenti, hogy van egy pár nagyobb szoftver van, amit elég rendesen fejlesztenek és sok hibát javítanak ki bennük (nekem mindössze 3 progiból kell a legújabb: gimp, inkscape és openoffice).De azért a stabilitást is meg szeretném tartani. Amikor először Testing-et telepítettem, az elő- előfordult hogy csontra fagyott. A munka gépemnél ez nem volt mindegy, mert volt hogy sok dolog futott: adat mentések tömörítéssel, különböző képek konverziói stb. Aztán fagyásnál gond: mik szakadtak meg, hol és hol kell kijavítani?

Ubuntu-val meg szerintem az a gond, hogy ott a rendszer magja is sok friss progit tartalmaz.

A java stuffokat a revdep sem kezeli. Nem, itt pusztán arról van szó, hogy egyes csomagok nem képesek ún. virtuális csomagoktól függeni, muszáj nekik konkrét csomagtól, holott maga a program ezt nem indokolná (java5-ös csomagot simán tolhat java6). Hát igen, csomagot írni tudni kell. A portage fában is van olyan csomag, amitől minden szál szőr égnek áll a hátamon...

( log69 | 2007. 10. 26., p – 12:26 )

Köszi mindenkinek a segítséget.

A CHROOT verziónál maradok végül, mert ennél akkor külön tudom frissítgetni a chroot-on belül a testing-emet és közben az alaprendszeremen megmarad a stabil is.

( log69 | 2007. 10. 26., p – 13:14 )

A topic teljessége kedvéért leírom pinyo_villany (köszi) által ajánlott debootstrap és chroot megoldást (tényleg benne volt a manual-jában a példa script, ezzel kellett volna kezdenem ;D )

Rendszer: Debian Etch 4.0

1) #apt-get install debootstrap

2) #cd /; debootstrap lenny /sid-root http://ftp.debian.org/debian/

3) #chroot sid-root

Ennyi, és már van is egy működő Testing-em. Viszont szerintem a Stable / Unstable páros a leghasznosabb, csak az unstable Sid-et nem hozza le rendesen. Keresgélés után találtam a neten a választ, hogy eggyel előbbi Testinget (Lenny) kell letölteni a Debootstrap-pel majd azt upgradelni. És így már működik is.

(Megj.: Az új CHROOT-os rendszer mappájának teljes mérete 190 MB lett. Semmiség ;D)

Mégegy kis kiegészítés:

A 'Locales' alapból nem kerül telepítésre és ezért néhány program futtatása az alábbi hibaüzenetet generálhatja:
Gtk-WARNING **: Locale not supported by C library.

Ennek egyszerű megoldása:
#apt-get install locales
#dpkg-reconfigure locales (itt pedig válasszuk ki az alapértelmezett nyelvi kódolást).

Sid upgrade-hez pedig:
#nano /etc/apt/sources.list (itt írjuk át a 'lenny'-t 'sid'-re)
#apt-get update
#apt-get dist-upgrade

Ennyi. Így tökéletesen működik nálam. Mennek az 'Unstable' repo-ból is a programok :D 


root@host ~ # mount --bind /home /chroot/home ű

Persze ehhez a chroot-ban illik ugyanolyan uid-del szerepelni, mint a host-on: 


root@host ~ # cd /etc
root@host ~ # cp passwd group shadow /chroot/etc

A cd kihagyható, és abszolút útvonallal is lehet másolni, de akkor a HUP a fejemre koppint, mert tiltott kifejezés a "per-etc-per-passwd"

Nagyon jó! Köszönöm szépen!
Már csak egy probléma van. A user-nek nem engedélyezett belépni a chroot-olt környezetbe.

#/usr/sbin/chroot /chroot-system/
/usr/sbin/chroot-system: a gyökérkönyvtár nem váltható át a következőre: /chroot-system/: A művelet nem engedett

Ezt hogy lehet kiküszöbölni? A user-nek gondolom be kell lépni először a chroot-ba, mielőtt ott programot futtatna...

Alakul, de még nem az igaz!

A sudoers file-om:
-------------------------------------
# Cmnd alias specification
Cmnd_Alias CHROOT_CMD=/usr/sbin/chroot

# User privilege specification
root ALL=(ALL) ALL
%sudo ALL = NOPASSWD: CHROOT_CMD
-------------------------------------
A user benne van a sudo csoportban.
Ennek ellenére nem találja a chroot parancsot.

$ sudo chroot /chroot-system
sudo: chroot: command not found

Mi lehet a gond?

Ha most a rendes alatt úgy érted, hogy a chroot-on kívülit akkor nem ( /home) .. Viszont az alap rendszer bele fog látni chroot-on belülre (/chroot/home).. ergo vagy át kell mindent cp-zned, a /home-ból a /chroot/home-ba hogy lásd az eredeti file-jaidat is, vagy amit a chroot-ban dolgozol azt a normál /chroot/home alá mented, és az alap OS-el meg már el tudod érni "kívülről"
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

Most bennem van a hiba vagy a leírásban?

Sid upgrade-hez pedig:
#nano /etc/apt/sources.list (itt írjuk át a 'lenny'-t 'sid'-re)

Egyáltalán hol említed, hogy a sources.list-be kell valamit is írni? o.O

De ha csak egy követhető leírás lenne stable verzión unstable csomagokat telepíteni, már annak is örülnék.

( utpKabel | 2007. 10. 31., sze – 16:15 )

Ötlet:
* /usr/local-ba fordítani új GTK-t, hogy az ne zavarja az /usr-ben már meglévőt.
* Fordítani GIMP-et, és közben valahogy úgy bekonfigurálni a linkert, hogy először az /usr/local-ban keresse a libraryket, és csak aztán az /usr-ben.

Én nem értek annyira ehhez, de aki ért hozzá az mondja meg, hogy ez működne-e így!

Elvben működne.
A ./configure --help megmondja, hol kell módosítani a dolgon, --with-gtk[=DIR] vagy ilyesmi sorokat keress
Ha mégse, lehet érdemesebb felrakni a gtk+-t, hold-ra tenni apt-ben, utána simán felülvágni a forrásból forgatottal. Persze ilyenkor nem lehet upgradelni, azt neked kell csinálni.

( log69 | 2007. 11. 07., sze – 19:46 )

MEGOLDÁS: Itt az általam használt és tesztelt megoldás (teljesség kedvéért) Debian Etch rendszerhez:
-----------------------------------------------------------------------------

1) DEBOOTSTRAP TELEPÍTÉSE
# apt-get install debootstrap

2) KÖNYVTÁRAK LÉTREHOZÁSA
(SHARED-et használom fájlok megosztására hogy teljesen elkülönítsem az adataimat)
# cd /
# mkdir /chroot-sid
# mkdir /chroot-sid/shared

3) DEBIAN LENNY (TESTING) LETÖLTÉSE ÉS TELEPÍTÉSE DEBOOTSTRAP-PEL
# debootstrap lenny /chroot-sid http://ftp.de.debian.org/debian/

4) A SZÜKSÉGES KÜLSŐ KÖNYVTÁRAK CSATOLÁSA
# mount --bind /dev /chroot-sid/dev
# mount --bind /proc /chroot-sid/proc
# mount --bind /sys /chroot-sid/sys
# mount --bind /tmp /chroot-sid/tmp
(itt akár a font könyvtárat is érdemes lenne 'mount --bind'-dal felcsatolni)

5) X SZERVERHEZ VALÓ CSATLAKOZÁS ENGEDÉLYEZÉSE
# xhost +local:localhost

6) HOST KONFIG LÉTREHOZÁSA
# echo "127.0.0.1 localhost" > /chroot-sid/etc/hosts

7) CHROOT
# chroot /chroot-sid

8) LOKÁLIS BEÁLLÍTÁS
# apt-get update
# apt-get install locales
# dpkg-reconfigure locales
(majd pedig válasszuk ki a megfelelő lokális beállítást, pl.: en_US.UTF-8 UTF-8)

9) REPO VÁLTÁS SID-RE
# echo "deb http://ftp.de.debian.org/debian sid main" > /etc/apt/sources.list
# echo "deb-src http://ftp.de.debian.org/debian sid main" >> /etc/apt/sources.list

10) RENDSZER FRISSÍTÉS
# apt-get update
# apt-get dist-upgrade

11) KÍVÁNT SZOFTVER TELEPÍTÉSE A SID-BŐL
# apt-get install gimp

12) FELHASZNÁLÓ LÉTREHOZÁSA
# adduser username

13) FELHASZNÁLÓ VÁLTÁS
# su username

14) DISPLAY VÁLTOZÓ BEÁLLÍTÁSA
$ export DISPLAY=":0.0"

15) PROGI FUTTATÁSA
$ gimp