apt-pinning, avagy hogyan használjunk hibrid Debian terjesztést

Debian

(A cikk megírását ez a fórum topic inspirálta)

Sokaknak szívfájdalma, hogy a Debian kicsit konzervatívabban kezeli az új csomagok befogadását a ``stabil'' terjesztésbe, mint más ``pengeél'' disztribútorok. Vannak akik szeretnék a stabil terjesztést követni - mondjuk a biztonsági frissítések miatt -, de eközben szeretnének egyes csomagokból a legújabbakat használni. Vajon lehetséges ez? Mi erre a legjobb megoldás?

A megoldás az, hogy miközben a ``stable'' terjesztést futtatjuk (jelen esetben a Debian 3.0r2 ``woody''-t), közben felhasználjuk a ``testing'' (most a ``sarge'') és az örök fejlesztői disztribúció az unstable ( ``sid'' - still in development) csomagjait, forrásait is.

Miért is jó ez? Azért, mert a ``stable - woody'' terjesztést követi a biztonsági csapat, és rendszeresen javítják a felbukkanó bugokat. A ``testing - sarge'' és az ``unstable - sid'' nem rendelkezik biztonsági frissítésekkel. Emellett lehetnek olyan kevésbé kritikus csomagok, amelyekből viszont szeretnénk a legújabbat használni. Ilyen lehet egy grafikus program (Gimp), egy levelező program, vagy egy bőngésző, stb. Ezeknél a programoknál nem túl gyakori a biztonsági hiba, így kisebb kockázattal lehet belőlük a nem követett verziókat használni, mint mondjuk egy ``bind''-ből. Ezeknél a programoknál jöhet szóba, hogy a ``testing''-ből vagy az ``unstable''-ből emeljünk be csomagokat.

Az apt fel van készítve arra, hogy több disztribúció csomagjait kezelje párhuzamosan. Lássuk hogyan:sources.list

Az első lépés a /etc/apt/sources.list módosítása. A ``stable'' disztribúciót követőknek ebben jelenleg a ``woody''-s forrás sorok vannak. Emellé kell felvenni a ``testing'' és az ``unstable'' sorokat. Egy egyszerű sources.list így fest:

#Stable

deb http://ftp.us.debian.org/debian stable main non-free contrib

deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free

#Testing

deb http://ftp.us.debian.org/debian testing main non-free contrib

deb http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free

#Unstable

deb http://ftp.us.debian.org/debian unstable main non-free contrib

deb http://non-us.debian.org/debian-non-US unstable/non-US main contrib non-free

Ezen sorok mellé természetesen fel lehet venni az egyéb extra forrás sorokat is, mint például a security.debian.org forrásait.

preferences

A következő lépés az /etc/apt/preferences file létrehozása/szerkesztése. Ebben a fileban adhatjuk meg a pinning stuffokat. Alapértelmezés szerint mindig a magasabb verziójú csomagok ``győznek'' a telepítéskor. Ezt viszont felülbírálhatjuk:

Egy egyszerű preferences file így fest:

Package: *

Pin: release a=stable

Pin-Priority: 700

Package: *

Pin: release a=testing

Pin-Priority: 650

Package: *

Pin: release a=unstable

Pin-Priority: 600

Megfigyelhető, hogy a ``stable'' a legmagasabb prioritású, a telepítéskor ez a preferáltabb a ``testing'' és az ``unstable''-lel szemben.

apt-get update

Ha ez megvan, jöhet a frissítés. Ezzel újabb repository-kat adhatunk az apt listájához.

E: Dynamic MMap ran out of room

A használat során az alábbihoz hasonló hibaüzenet köszönhet vissza:

E: Dynamic MMap ran out of room

E: Error occured while processing sqlrelay-sqlite (NewPackage)

E: Problem with MergeList /var/lib/apt/lists/ftp.us.debian.org_debian_dists_woody_contrib_binary-i386_Packages

E: The package lists or status file could not be parsed or opened.

Ez azért van, mert az apt cache túl kicsi ahhoz, hogy a ``testing''-et és az ``unstable''-t is kezelje a ``stable'' mellett. Ez hiba egyszerűen fixálható. Az alábbi sort kell az /etc/apt/apt.conf fileba felvenni:

APT::Cache-Limit "8388608";

Új csomagok telepítése

Az új csomagok telepítése egyszerű. Mint korábban az apt-get install paranccsal most is telepíthetünk. Ha a csomag megtalálható a ``stable'' terjesztésben, akkor az települni fog. Ha a csomag csak az ``unstable''-ben található csak meg, akkor onnan fog települni.

``De mi van akkor, ha a csomag megtalálható a ``stable''-ban és az ``unstable''-ben is, de mi az ``unstable''-ban levőt szeretnénk telepíteni?'' - hangozhat a kérdés.

Két utat választhatunk. Mindkét megoldás más szintaxissal működik, és mindegyiknek más a hatása:

  • apt-get install /unstable

Ez telepíti a csomagot az ``unstable''-ből, de a ``stable''-ből próbálja meg a függőségeket rendezni. Ha nem tudja, akkor szól:

# apt-get install zsh/unstable

Reading Package Lists... Done

Building Dependency Tree... Done

Selected version 4.0.6-7 (Debian:unstable) for zsh

Some packages could not be installed. This may mean that you have

requested an impossible situation or if you are using the unstable

distribution that some required packages have not yet been created

or been moved out of Incoming.

Since you only requested a single operation it is extremely likely that

the package is simply not installable and a bug report against

that package should be filed.

The following information may help to resolve the situation:

Sorry, but the following packages have unmet dependencies:

zsh: Depends: libc6 (>= 2.2.5-13) but 2.2.5-11.1 is to be installed

E: Sorry, broken packages

  • apt-get -t unstable install

Ez a megoldás a csomagot az ``unstable''-ből próbálja meg telepíteni, és a függőségeket is az ``unstable''-ből próbálja meg rendezni. Ez talán a könnyebb út:

# apt-get -t unstable install zsh

Reading Package Lists... Done

Building Dependency Tree... Done

The following extra packages will be installed:

libc6 libc6-dev libc6-pic libdb1-compat locales

The following NEW packages will be installed:

libdb1-compat

5 packages upgraded, 1 newly installed, 0 to remove and 394 not upgraded.

Need to get 11.6MB of archives. After unpacking 606kB will be used.

Do you want to continue? [Y/n]

Ennyi az egész.

Ha felkészülsz egy jó sources.list-tel és egy preferences file-lal, akkor sikeresen szörfözhetsz a különböző Debian kiadások között.

Természetesen mindenki csak saját felelősségére használjon nem stabil terjesztést! A biztonsági rés lehetősége - még ha kisebb métékben is - benne van ebben a metódusban.

PS (RTFM): man apt_preferences

Jó szórakozást!

(Köszönet Friczy-nek, aki ezt a metódust kb. 1 évvel ezelőtt bemutatta)

( ignotus | 2003. 12. 03., sze – 19:12 )

Cool cikk, apt-pinning olyan dolog amit abszolut tudnia kell minden
Debian usernek (aki maga tartja karban a gepet); nekem csak az a
szivfajdalmam hogy tobb unstable agat nem tud (vagy csak regen neztem at
a doksikat?), pl. en ossze-vissza hasznalom az igazi unstable-t meg egy
regi snapshot unstable agat, eleg korulmenyes a valtogatas
(sources.list-ben egyiket kommentezni, utana apt-get update stb)... :)

deb http://snapshot.debian.net/archive/2003/08/15/debian unstable main
deb ftp://ftp.hu.debian.org/debian/ unstable main

Aki nem ismerne snapshotot:

*Mojojojo* ignotus, debian-snapshot => Ha valami uj csomag
esetleg szetnyomta a rendeszeredet, akkor itt megtalalod a
debian.org napi snapshotjait es leszedheted a meg a szar
csomag (elozo) mukodo verziojat: http://snapshot.debian.net

--
....sutongi tti olleh

Ez már valóban nem egyszerű, de egyes csomagokra külön adhatsz meg priority értékeket, és a priority között nem csak terjesztés szerepelhet, hanem verziószám is. (Erre akkor volt szükségem, amikor X-et akartam nem hivatalos forrásból telepíteni, és hiába volt magasabb verziójú X a sources.listben, nem tudtam behúzni, hogy frissüljön.)

Akkor Pin: version 4.3.* értékeket kellett megadni a csomagokra.

( Friczy v | 2003. 12. 03., sze – 20:06 )

Annyit hozzátennék, hogy source csomagokra kicsit másképp működik: ott apt-get source &lt csomagnév &gt=&lt verziószám &gt

( szaszg | 2003. 12. 03., sze – 20:35 )

Hali trey!

Csak annyit szeretnek hozzatenni (amit a forumban is megprobaltam leirni), ha ilyen "mixelt" rendszert csinalunk, akkor az osszes felrakott "testing/unstable" csomag -- marmint a fuggosegek is "testing/unstable" lesz, nemcsak az az egy, amit felteszunk. Ha forrasbol forditunk, akkor (tobb esellyel) tenyleg csak az az egy csomag lesz hmmm... "kompromittalt".

Zsiraf

( nevergone v | 2003. 12. 03., sze – 22:50 )

Ha ezt a megoldást ismertem volna... maradok a stable-nel... :)

( samson | 2003. 12. 03., sze – 22:52 )

Hali.

Ez mind nagyon szep es jo.

Van egy par megjegyzesem:

A legtobb testing/unstable csomagnak nem jo a stable-ben levo libc. Azaz a libc kapasbol frissulni fog. Es meg rengeteg mas lib.

Szerveren nem hiszem, hogy szukseg lenne gimpre vagy mozillara, tehat ebben az esetben nem tudom elkepzelni az ilyen mix rendszert. Ha meg kell vmi, akkor backport...

Workstation-re meg olyan mindegy, nem? Az ugyis tele lesz testing/unstable csomagokkal, s ekkor mar erdemes inkabb csak magat a testinget/unstablet hasznalni, mint keverni.

Serveren valóban nem jó keverni ezeket, ott én is backportolni szoktam.
A workstation esetében viszont nekem pl. alapból testing van, de ha
valamire mégis frissebb csomagra volna szükségem, akkor általában gond
nélkül felrakom az unstableból. Teljes egészében viszont nem szeretnék
sidet használni desktopon sem, mert időnként nagyon meg tud(na) lepni,
azt meg nem akarom :)

Persze ha ilyenkor lecserélné a fél rendszeremet, azt nem hagyom.

--
--- Friczy ---
'Death is not a bug, it's a feature'

( garaboncias | 2003. 12. 04., cs – 02:15 )

Ide tartozik, hogy leforditottam az APT hogyan-t elérhető itt [people.inf.elte.hu]
aki ért hozzá, az nézze már át mert lektorálásra vár.
Aki meg nem ért hozzá és Debianja van, annak meg kötelező olvasmány :-)


Üdv Garabonciás

( mge | 2003. 12. 04., cs – 02:43 )

A libc frissités tényleg elég gáz, könnyen hazavághat mindent. :(

Van viszont ket kevésbé fájdalmas lehetőseg:

deb http://.... stable main ...

deb-src http://... unstable main ...

apt-get source csomagnév.

Fordít, telepít, használ.

A másik megoldás, hogy ellátogatunk a www.apt-get.org oldalra, és megkeressük, hol van az adott csomagbol backportolt példány. Az itt megkapott címet a sources.list végére írjuk, és ízlés szerint a pinninget is beállítjuk hozzá.

hat en eles kornyezetben elfelejtenem az apt-get.org-ot. Senki nem ellenorzi, nem hivatalos Deban projekt, szinte barki feltolthet csomagot, stb. Egy biztos, en onnan eles szerverre - amiert en felelek - nem teszek ismeretlen forrasbol fel csomagot.

>apt-get source csomagnév

ez egeszen addig mukodik, amig a csomagnak nincs valami komolyabb fuggosege. Aztan ugyanott vagyunk.

> Szerveren nem hiszem, hogy szukseg lenne gimpre vagy mozillara, tehat ebben az esetben nem tudom elkepzelni az ilyen mix rendszert

Ez az iras nem is a szervert uzemeltetoknek keszult. Egy szerveren en nem hiszem, hogy mindenbol a legujabbat kellene hasznalni.

Egyszeruen azert irodott ez az iras, mert tapasztalat, hogy azok kozul sem ismerik nagyon sokan ezt a featuret akik kulonben mar evek ota Debi Janosok.

samson-nak teljesen igaza van!

egy ilyen apt-pinning-el hamar eljutunk oda, hogy az áhított stable alapokon nyugvó pár új csomagot tartalmazó rendszer helyett, egy tulajdonképpen downgrade-elt testing/unstable Debian-unk lesz (nincs security update!!!)

Zsiráf

miert a backporttal hova fogsz eljutni? Ha tf. backportolsz egy olyan alkalmazast, aminek ujabb libc kell, akkor hogy fogod hasznalni a regebbivel? backportolod a libc-t is?

megerkeztunk ugyanide.

annyi kulonbseggel, hogy igy egy paranccsal el lehet intezni egy telepitest, nem kell hozza devel kornyezet (a forditashoz), konnyebb kezelni, es stb.

Ha meg backportolsz, az mennyivel biztonsagosabb? Az unstable csomag forrasbol forgatsz stable-re.

Senki nem allitotta, hogy ez igy biztonsagos. Aki backportot hasznal, vagy ezt a megoldast az mar nem stable-t hsznal. Akiknek biztonsag kell, az ne ugraljon. Maradjon a stable-n. Ezt mondja a Debian is.

> Ha tf. backportolsz egy olyan alkalmazast, aminek ujabb libc kell, akkor hogy fogod hasznalni a regebbivel? backportolod a libc-t is?

Ez szerintem nagyon specialis eset, en meg nem talalkoztam olyan programmal, aminek feltetlen ujabb libc kellett volna, mint ami a woodyban van. (Most a source-bol backport-rol beszelek.) Bar az is igaz, hogy nem vagyok olyan hatalmas ,,backporter'', nehany csomag van amiket rendszeresen leforditok testingbol woodyra.

Igen szamos esetben mukodik a backport. Nem is vitatom. Megyeget az SQL szerver a regi kornyezetbe visszaportolva. De vajon mert mar ezeken valaki mondjuk teljesitmenyt? Vagy egyszeruen eleg volt, hogy elindult az alkalmazas, es orult neki, hogy mukodik. Az hogy neha mondjuk ttokzatos modon leallt egy szerviz, azt meg betudtuk a csillagok allansanak.

Annak, hogy a masik terjesztesben mondjuk libc-t valtottak nyilvan oka volt. Kulonben miert valtottak volna?

Nem allitom, hogy nincs a backportnak letjogosultsaga. De:

1.) nem mindenki kepes debian csomagot alolallitani

2.) nem minden esetben van lehetoseg debian csomagot alollitani (aki dologzott mar olyan kornyezetben, ahol az ido tenyezo volt a legfontosabb, az tudja)

3.) ez egy hivatalos debian ut, inkabb ezt valasztom, mint mondjuk az apt-get.org -rol egy ketes eredetu csomag telepiteset, amivel neadjisten egy jo kis rootkit is telepul.

Akinek van energiaja, megfelelo gepe, ideje, szaktudasa, az nyilvan a backport mellett dont. Akinek ezek kozul valamelyik nincs, az lehet, hogy ezt valasztja.

meg valami jutott eszembe. pro-s kontra

backport mellett:

ha mar ujraforitod, akkor lehet CPU-ra optimolni. Bar ennek csak akkor van ertelme fokent ha az egesz rendszert ujraforditod.

a pinning mellett:

nem kell torodni a gcc verzioval, nem eshet meg az, hogy egyik regi gcc-vel a masik ujjal van forditva, aztan az istennek nem akar egyutt menni. a backport jo lehet, amig egyszeru csomagokat kell visszaportolni (vi, mutt, mittomen), de probalj meg egy X servert, vagy egy komolyabb alkalmazast visszaportolni. Lehet laikuskent beleoszulsz.

Hé trey!

Kissé fáradt vagy:

De vajon mert mar ezeken valaki mondjuk teljesitmenyt? Vagy egyszeruen eleg volt, hogy elindult az alkalmazas, es orult neki, hogy mukodik. Az hogy neha mondjuk ttokzatos modon leallt egy szerviz, azt meg betudtuk a csillagok allansanak.

Már ne haragudj, de vajh mekkora teljesítménykülömbség van mondjuk fopen, fprintf, fscanf, getch, printf, select, stb, stb-ben mondjuk egy glibc-2.2.5 és egy 2.3.2 között??? te mérted már valaha ????

Olvasgattál már glibc Changelog-ot??

A fene nagy multiplatformitás miatt, még a kínálkozó GNU extension-okat sem használják a standard programokban...

Másik:

miert a backporttal hova fogsz eljutni? Ha tf. backportolsz egy olyan alkalmazast, aminek ujabb libc kell, akkor hogy fogod hasznalni a regebbivel? backportolod a libc-t is?

megerkeztunk ugyanide.


trey, trey! a backport éppen azt jelenti, hogy pl. a standard woody-s konyvtárak között tud majd működni a programod. Épp arról van szó, hogy a régi könyvtárakkal fordítod le. :-) Láttál már olyan backportot, amineg a sid-ben lévő glibc kellett? :-o

Zsiráf

Az X nem túl jó példa, mert viszonylag nagyon könnyen engedelmeskedik :-)) Minden i8x-es gépemen az unstable-ból backportolt X fut :-) (kénytelen voltam :-()

De valóban létez(hrt)nek olyan programok, amiket nem lehet backportolni. Senki sem mondta, hogy mindent lehet, és ez áll mindenek felett, csak azt mondam, hogy így kevesebb hmm hmmm possible security hole ficereg a gépeden. Ennyi és nem több.

Zsiráf

>trey, trey! a backport éppen azt jelenti, hogy pl. a standard woody-s konyvtárak között tud majd működni a programod. Épp arról van szó, hogy a régi könyvtárakkal fordítod le. :-)

Ne nezzel mar enyire madarnak. Arrol beszeltem, hogy le akarod forditani, es nem tudod. Akkor mit csinalsz. Te mar arrol beszelsz, hogy leforditottad.

Nem egyrol beszelunk. Most ne csak a libc-nel ragadj le, ezer mas fuggosege lehet egy csomagnak. Mondom. Backportolj X szervert vagy valami komolyabb dologot. Meglatod, hogy nem csak abbol all, hogy lehuzod a sid forrast, aztan felforgatot. Szep is lenne, ha ez igy magaban mukodne.

PS: bold nelkul is latok. :-)

PS2: nem kotelezo neked az apt-pinning-et hasznalni. Vannak joparan akik hasznaljak, bevalt nekik (pl. nekem is). Te meg backportolj szorgalmasan. Ha esetleg nyitsz a backportjaidbol egy repo-t az meg megjobb. Akkor szolj, es mindenki boldog lesz.

a pinning mellett:

nem kell torodni a gcc verzioval, nem eshet meg az, hogy egyik regi gcc-vel a masik ujjal van forditva, aztan az istennek nem akar egyutt menni.

Miert ne eshetne meg, sőt. Woodyban még 2.95 volt a gcc, sarge-ban és sidben pedig mar 3.3.

> Annak, hogy a masik terjesztesben mondjuk libc-t valtottak nyilvan oka volt. Kulonben miert valtottak volna?

Termeszetesen, a fejlesztes nem all meg, az ujitasok nyilvan hasznosak is valahol, ergo egy friss terjesztesben nem feltetlen eri meg ragaszkodni a regebbi libc-hez. Teljes egyetertesben a felhozott harom pontoddal, csak egy plusz megjegyzes.

Rogton az elso esetben mikor egy meg abs mertekben tiszta woodyra felteszel egy mas brachbol szarmazo csomagot (apt-pinningen keresztul), azonnal frissiteni fogja a libc-t. (Hacsak nem egy akarmilyen libperl-foobar csomagot teszel fel eppen, vagy vmi olyat aminek semmi koze a libc-hez. :-) Ezutan ha akadnak olyan woodys csomagok amelyeknek nem tul rugalmas a Dependecy listajuk, ertsd: kerek perec meg van mondva benne, hogy marpedig neki a woodys libc kell, akkor azonnal broken lesz a csomag. Persze, errol te nagyon nem tehetsz, vagy szolni kell a binaris csomag maintainerjenek es o megvaltoztatja (megjegyzem, ettol meg nem fog bekerulni a sec.deb.org-ra); vagy pl. nagyon is jo oka van arra, hogy a depend listaban nem >= hanem csak = szerepel.

Dehogynem válaszoltam :-)

Azzal, hogy nem backport mindenek felett... Semmi kifogásom a pinning ellen, csak arra akartam felhívni a figyelmet, amire már többször is próbáltam rámutatni, hogy pinningel hamar eljutunk a testing/unstable rendszer downgrade-elvéhez a stable néhány újabb csomaggal helyett! (csakazértis bold-al, hogy kiszúrja trey szemét). Akinek ez jó, az csinálja, de ne higyje azt, hogy továbbra is a stable mellé járó security upgrade "védelmében" él (ha jól megforgatta a dolgokat :-).

Zsiráf

Az X rossz példa volt trey :-)

Én a laptopomon woody-t használok, saját backportolású 4.3-as X-el :-)

Igaz, hogy egy csomó más vackot is kénytelen voltam backportolni (libnewt, debhelper, stb.), amit nem szerettem volna, és emiatt nem is tettem közzé, ahogy szoktam... De azt kell hogy mondjam, a 4.3-as X backportolása kispálya volt az experimental repóban lévő postfix snapshot woody-ra backportolásához képest, amit idő híján, még mindig nem fejeztem be :-)

Egy binárisnak általában tök mindegy, hogy hányas gcc-vel fordítod, illetve linkeled!

Egy helyen nem mindegy: A hülye C++ libeknél, ahol gcc minor verziók közt is változik az ABI...

Vagyis egy C++ lib-et, ha 3.2 gcc-vel fordítasz, akkor azt 3.3-as gcc-vel már nem fogod tudni használni.

De XFree-ben szerencsére egy fia C++ kód sincs...

Mit gondolsz, mi a csodáért szidják annyit MPlayerék a C++-t?!

De kérdezd csak meg al3x-et! Ő tud neked válogatott káromkodásokat/kínzásokat mondani a C++ háza tájáról :-)

Erdekes en ezt nem tapasztaltam. Forgass kernelt 2.95 gcc-vel, meg kernel modult mondjuk 3.x-szel. Mindjaert meglatod mennyire nem mindegy. De felhozhatom peldanak a Mozilla + Java plugint is.

Lehet, hogy elvileg mindegy. Csak a gyakorlat nem mindig igazolja az elmeletet.

(nem veletlenul van sanity check sok program forditasakor a gcc-re)

> miert a backporttal hova fogsz eljutni? Ha tf. backportolsz egy olyan
> alkalmazast, aminek ujabb libc kell, akkor hogy fogod hasznalni a
> regebbivel? backportolod a libc-t is?

Az esetek nagy reszeben a csomag leforditasahoz nem kell az ujabb libc.
Csak azert van benne a fuggosegben, mert az adott csomagot mar ujabb
libc-vel keszitettek. Ilyen esetben a backport gond nelkul megy. Ami a
forditashoz kell, az az adott csomag build-depend reszeben van benne.

Az egesz nem a biztonsagrol szol egyebkent, aki biztonsagot akar, az
hasznalja a stable-t.
--
--- Friczy ---
'Death is not a bug, it's a feature'

Tudom...

Viszont a sarge es a sid csomagjait a 3.3-assal forgattak, nem a 2.95-tel, igy ha ezekbol teszel fel valamit woodyra, akkor azokat nem ugyanazzal a gccvel forgattak, mint a woody tobbi reszet. Tehat pinning eseten eppenhogy lehet gaz a kulonbozo gcc verziok miatt.

( Luki | 2007. 04. 18., sze – 22:43 )

> (Köszönet Friczy-nek, aki ezt a metódust kb. 1 évvel ezelőtt bemutatta)
Én pedig köszönöm neked, trey, hogy ezt a cikket megírtad, mert egy bug miatt (#263280: vpnc: failure to reconnect soon after a disconnect) hibrid rendszert használok, és ez módszer megoldotta a problémám. :-)

UI:
> (A cikk megírását ez a fórum topic inspirálta)
A hivatkozás meglehetősen elavult. :-) Lehet/érdemes javítani?

( Celtic v | 2009. 02. 22., v – 22:53 )

Most igy az etch -> lenny frissites kapcsan felmerult bennem, hogyan tudom megmondani, hogy honnan szedje a csomagokat. Anyamnak havi 1G nete van, igy maradt a "letoltom, kiirom DVD-re, postazom, gepbe berakja" es onnan ssh-n upgrade-elem.
Namost, "apt-cdrom add" utan vagy kikommentelem a tobbi forrast vagy van mas megoldas is? Tehat, hogy elsodlegesen ne a netrol szedje a cuccost, hanem a cd-rol.