Už mě ten balíčkovací systém Slackware pěkně s*** (diskuse)

[Martin]

Odpovídám "Arch Linux" a přeji příjemnou flamewar :o)

[jalinh]

Není distribuce kromě Debianu a Kubuntu je jeho prorok *SVATOST*

[pasmen]

Ja dlouhou dobu (2 roky) pouzival Slackware k plne spokojenosti, ale ten balickovaci system byl pravda neco, co mi taky trochu vadilo. Nedavno jsem objevil Arch, a je to v podstate Slackware s poradnym balickovacim systemem. Doporucuju.

[XMurder]

Jen škoda že Arch je jen pro i686 a ne starší...

[Jan Březina]

což je mimo jiné ted důvod, proč mě Arch moc nezajímá :-/

[Lukáš Rýdlo]

No, na své třiosmšestce asi nechám slackware , ale naštěstí mám i jiné kousky (dnes již také považované za muzejní ), kterým je i686 takříkajíc blízké

A na "server" (který bych měl brzy získat) stejně hodím Slackware. Jakou firewall/router a web (popř. i ftp) server bude ideální...

[kreten]

jo jo... tak o své distro se taky snažím. Prostě základ a ostatní klidně natvrdo nalinkované. vždit kdo dneska má disk pod 300GB a nemá 64bit je žabař! ))

[pol128]

Čo k tomu povedať. Snáď len

Keep on Slackin'

[Zdeněk Štěpánek]

No asi takhle. Ve Slackwaru doten neni HAL ani DBUS (balicky jsou, ale nechodi to). a novy KDE to ma zrejme jako povinnou zavislost. Takze kdyz kliknu na ikonu CD, vyskoci "Tato funkce je dostupna pouze v HAL." a basta, CD nefunguje. A neni to jen muj púocitac, zacalo to delat uplne vsude.

Takze predelavam vse na Arch. Uz mam nainstalovano, jen nakopirovat na cilovy kompy. A je to i rychlejsi.

Zdenek

[pol128]

Ale to je potom veľmi zaujímavé, že mne v slacku ide hal aj dbus úplne bez problémov. Asi mám iný slack

[happy barney]

slack? kliknut? uff
na balicky pouzivam linuxpackages.net, ked clovek vie co robi, ziaden problem

[Zdeněk Štěpánek]

No tak ja jsem si tyhle chyby u sebe vsiml az potom, co mi lidi davali vedet ze jim nefunguje pocitac. Tatu/mamu ani kamose nebudu nutit to delat jiank nez chteji, kdyz to ten system ma umet.

Zdenek

[Zdeněk Štěpánek]

Tak jestli muzu prosit, tak mi poradte. Rekl bych ze slack znam dost dobre, pouzivam, ho uz par let na nekolika strojich. Repozitar z linuxpackages mam primo ve swaretu.

HAL je tam dvakrat, je potreba nainstalovat starsi verzi, jinak nefunguje dbus (ketyr je tam jen jednou). Takze ackoliv jsem oboje stahnul i se zavislostma, oboje spustil, KDE porad kricelo tu trapnou chybu.

Zrovna jsem v praci resuscitolal jeden stroj se slackem co pul roku lezel, no a po upgardu to samozrejme prestalo fungovat.

Zdenek

[Dunric]

1. Oficiální balíček kdebase je zkompilován bez podpory HAL, tzn. je nutné jej překompilovat.
2. Jelikož závislost KDE na HALu/D-Busu je min. do verze 3.5.4 volitelná, bylo už toto chování nahlášeno jako chyba, která snad bude v další verzi odstraněna.
3. Vřele se nedoporučuje míchat balíčky určené pro různé verze Slackware. Usuzuji tak proto, že popsaná chyba se objevila až v KDE 3.5.4, které není součástí release 10.2, pro který jsou sestavovány balíčky z Linuxpackages.net, ale je až ve verzi -current, resp. 11RC4.

[......]

Naštěstí takové kraviny nepotřebuju

[Dunric]

Ten zápisek jsem nějak nepochopil.

Co má společného balíčkovací systém s nějakým zmršeným balíčkem z třetí strany ?
Pokud je potřeba sw, který není oficiálně ve Slackware obsažen, tak se to obvykle řeší kompilací ze zdrojů (nejlépe přes SlackBuild) nebo se holt sáhne po hotovém se všemi riziky z toho plynoucími.

Systém neřeší automaticky závislosti, tj. je nutné je manuálně doinstalovat. Strukturou oficiálních balíčků a i při používání vlastních buildů toto kupodivu není handicap, ale naopak pohodlný a maximálně jednoduchý nástroj úplné kontroly nad nainstalovaným software.

Nevím co bylo myšleno tím jak autoři vymýšlejí názvy balíčků. Balíčky se označují standardizovaným a IMHO konzistentním způsobem. Více viz např. tento dokument (PDF) .

[Lukáš Rýdlo]

> Co má společného balíčkovací systém s nějakým zmršeným balíčkem z třetí strany ? Balíčkovací systém má s tím zmršeným balíčkem společné úplně všechno vyjma obsahu Jelikož ten balíček je balíčkem pro daný balíčkovací systém. Nechápu, jak je možné, aby existoval např. balíček ekiga a Ekiga a byly vedeny jako dva různé. Nechápu, jak je možné, že běžnými prostředky jen těžko zjistím, jak je pojmenovaný balíček s konkrétní aplikací, protože název aplikace a balíček mívají občass málo společného a jediné vyhledávání balíčků na základě obsažených souborů jsem našel na slackware.com a je k ničemu...

> se to obvykle řeší kompilací ze zdrojů Ano, ale pak je ten balíčkovací systém zbytečný, pokud stejně musím velkou část věcí kompilovat ze zdrojů.

> Systém neřeší automaticky závislosti A to je chyba. Měl by dát na výběr, zda chci doinstalovat závislosti nebo se s tím drbat ručně... Od čeho jsou počítače? Abych si bokem na papírek poznamenal, co ještě musím doinstalovat než můžu nainstalovat tento balíček?

>maximálně jednoduchý nástroj úplné kontroly To je asi vtip, že? Pokud musím ručně řešit závislosti, systém mi při updatu zanechá nainstalovanou i starou verzi (udělal mi to s pwlib a teď to vypadá, že to byl ten problém -- nainstalovalo to sice novou pwlib, ale ta nebyla vidět, protože ji "přebila" ta starší) místo aby ji smazal, když povýšil... Nemluvě o faktu, že půlka software z balíčků a půlka ze zdrojáků dělá v systému celkem bugr...

Jinak díky za to PDF. Rád si to přečtu a třeba pak líp pochopím filosofii slackwarovského balíčkovacího systému...

[Dunric]

huh ??

Nechápu, jak je možné, aby existoval např. balíček ekiga a Ekiga a byly vedeny jako dva různé.

Za prvé si uvědomte, že pokud používáte _neoficiální_ repozitáře a někdo tam přibastlí balíček, který porušuje standardy, tak brečte tam. Za druhé v *nixech, resp. shellech, se standardně rozlišuje velikost písmen a to patí i pro rpm, který asi znáte z FC. To, co popisujete, se vám s oficiálními repozitáři nestane.

Nechápu, jak je možné, že běžnými prostředky jen těžko zjistím, jak je pojmenovaný balíček s konkrétní aplikací ...

Http, ftp nebo rsync klienta považuji spolu s bzipem za běžné prostředky a každý repozitář mj. obsahuje komprimovaný soubor MANIFEST, který obsahuje záznamy o všech souborech včetně úplných cest. Pokud chcete automatizované prohledávání, nainstalujte si např. slackpkg a přečtěte si v manuálové stránce o volbě search. Je v balíčcích podstromu extra.

> Systém neřeší automaticky závislosti A to je chyba. Měl by dát na výběr, zda chci doinstalovat závislosti nebo se s tím drbat ručně... Od čeho jsou počítače? Abych si bokem na papírek poznamenal, co ještě musím doinstalovat než můžu nainstalovat tento balíček?

Nechci se opakovat, ale takhle to nefunguje. Pro zkušenějšího uživatele toto představuje minimální přítěž, kterou jednou a na dlouho vyřeší a vyhne se v praxi velmi běžným zbytečným závislostem. Aby toto bylo možné v rpm, dpkg nebo FBSD Portech, musela by být granularita jejich balíčků násobně vyšší, což je nereálné. Nejblíž je tomu Debianí PM s volnými závislostmi, ale i tak člověk občas narazí. Ale každému co jeho jest.

>maximálně jednoduchý nástroj úplné kontroly To je asi vtip, že? Pokud musím ručně řešit závislosti, systém mi při updatu zanechá nainstalovanou i starou verzi

Ne, není. Pokud neumíte pracovat s motykou a ukopnete si palec u nohy, je to vina motyky ? Opravdu nechápu jak provádíte updaty, ale upgradepkg, který je mj. transparentně volán ze slackpkg, slapt-getu nebo swaretu vám vždy nejdříve odlišnou verzi odstraní a pak nainstaluje novou.

Nemluvě o faktu, že půlka software z balíčků a půlka ze zdrojáků dělá v systému celkem bugr...

Jen u "čuňátek", která instalují přímo do filesystému Normální lidi instalují vždy přes balíčky. Pro méně zkušené je tu checkinstall, pro ostatní SlackBuildy.

[thingie]

Tady vzniká ten problém, a nebojme se to říct, že v oficiálních repozitářích Slackware je víceméně houby

[Dunric]

700 balíčků oproti třeba Debianím 15k je víceméně houby, ale někdo spíš preferuje kvalitu nad kvantitou A IMHO ze základního sw jak pro server tak pro desktop tam nic nechybí. Osobně mám tak do 5% balíčků vlastních, zbytek jsou oficiální. Pokud mu skladba software, balíčkovací systém nebo jiné věci nevyhovují, není nic jednoduššího než si vybrat jinou vhodnější distribuci

[......]

V tom případě nechápu proč si člověk, co tohle nechce dělat a není s tím smířený, vybere Slackware. Od toho jsou tu jiné distribuce, nebo ne?

[Zdeněk Štěpánek]

Ten zápisek jsem nějak nepochopil.

Co má společného balíčkovací systém s nějakým zmršeným balíčkem z třetí strany ?

No to samozrejme moc spolecneho nema, jen to pro me byl posledni hrebicek do rakve.

[Ondrej]

Na instalaci softu doporucuju swaret a linuxpackages.net. Nemam s tim vubec zadnej problema uz se tesim jak az Patrik oficialne vyda S11 jak necham na 4 kompech swaret stahovat xy MB novejch balicku. Musim nejak vychytat lokalni swaret mirror

[David Watzke]

Co dodat...

Keep Gentooin'

[Tomáš]

Už mě ten balíčkovací systém Slackware

To on už konečně nějaký má, jo?

[zvovka]

Zdravím, no většina důvodů, které tady autor vyjmenoval jako problematické, mě donutily přejít k Fedoře na desktopu a 'redhat base' distrech na serverech.

Nevadil mi ani tak balíčkovací systém. protože pomocí swaretu to nebyla (tehdy, cca 2 roky) žádná tragédie, horší to bylo právě s těmi neoficiálními repozitáři - na desktopu nutnost - a frekvenci upgrade u oficiálních balíků. Linuxpackages.net tehdy - dnes nevím - to byl příklad toho jak nevytvářet repozitář, balíky byly kompilované proti zbytečným knihovnám a 'neočekávaným' verzím programů (tehdy jsem pochopil co je to dependency hell), pamatuju se, že někdy se tam nějakým způsobem zapletlo i 64 bitů (/usr/lib vs /usr/lib64)! Něky se záplatovalo slušně rychle, ala někdy se člověk načekal než si Patrick V. sedl a všechno to nabuildoval!

Taky se mě nelíbila závislost na jediném člověku, tehdy ještě podpořená nemocí P.V.

Všechno tehdy spělo k 64 bitům, Slackware poskočil na 486... dneska nemá defaultně ani kernel 2.6.x. Je pravda že přeložit si do Slackware cokoliv v podstatě není problém, ovšem jinde je to, díky dostupným a funkčním balíkům, daleko jednodušší {přiznávám to je možná spíš můj problém - Slack je i o tomto}.

Nicméně jinak je Slackware po stránce konfigurace a transparentnosti fungování opravdu to nejlepší s čím jsem měl tu čest u Linuxu setkat (pamatuju se jak strýček Grumpa někde říkal že nejlepší na desktop je Slackare bez X], ale (IMHO) bohužel se současným přístupem (onemanshow, jedna architektura, co nestíhám vyřadím=Gnome, atp.) pude do kytek.

Trochu alibisticky ještě dodám že dění kolem Slackware v podstatě nesleduju a jestli se blýská na lepší časy a opravdový progres (ne jen nové verze programů každého půl roku a vychytanější skripty), tak se omlouvám za 'toppic mimo mísu'. Slack mám na 'serveru' doma a na qemu v práci a mazlím se s ním jako mamrd, teda člověk, který má dost času na to být SLACK.

[......]

s tím jádrem jsi trošku mimo mísu. Jádro 2.6 se nachází na druhém instalačním CD a nemusíš absolutně nic kompilovat.

Jinak k tomu remcání na Slack:

a) nikomu ho nikdo určitě nenutil

b) měli byste uznat, že až tohle distro člověka naučí pořádně dělat s linuxem.

[zvovka]

Nejsem mimo mísu, napsal jsem že není defaultně k dispozici (ale dobře je to jeden parametr při instalaci navíc - OK), navíc politika vanila jader (což vždycky byla politika Slacku) je u řady 2.6.x dost problematická, navíc ty vycházejí ve frekvenci že se při update Slacku bude stahovat jako u Gentoo (no flame).

[Mikos]

Můj názor na Slackware sem již vyslovil mnohokrát - používat ho na desktopu je čirý masochismus A platilo by to i o jakékoliv jiné distribuci, která nativně neřeší závislosti (slapt-get či swaret za řešení nepovažuji, to je obcházení problému... navíc se nedají co do kvality s balíčkovacími managery jako pacman, portage či apt-get absolutně srovnávat).

A není to jediná věc co mi na Slackwaru vadí (btw. než mě někdo nařkne že nevím o čem mluvím, tak musím předeslat že mám se Slackwarem poměrně dlouhou zkušenost a na routeru ho bohužel stále ještě používám). Nesmyslně malé množství balíčků (které člověka nutí ke kompilaci ze zdrojáků a následnému ručnímu sledováním zda daný program nemá novější verzi... nebo nedej bože použití neoficiálních repozitářů jako Linuxpackages, kde je kvalita balíčků často velmi pofidérní), některé balíčky v nehorázně zastaralých verzích (Apache 1.x místo Apache 2.x, atp.), vývojový model ve stylu One-Man-Show (což se mi osobně opravdu hooodně nelíbí), atp.

Jediné co se mi na Slackwaru líbí je jeho čistota a jednoduchost, ale to mám i u Arch Linuxu který já osobně považuji za nesrovnatelně lepší (i když lidem co nemají rádi rolling-updates filosofii se zamlouvat nebude ). Prostě a jednoduše považuju použití Slacwaru na desktopu za masochismus. Někomu to možná vyhovuje, ale mě tedy určitě ne Slackware dle mého názoru tak trochu zaspal dobu, je to relikt minulosti I když je mi jasné, že spousta lidí co jsou na něj zvyklí ho bude používat nadále... a i na serverech má v jisých specifických případech ještě pořád možnost uplatnění.

[Mikos]

Eh, sem si to teď po sobě ještě jednou přečetl a koukam že by z toho mohl být dost drsný flejm To nebyl můj cíl, omlouvám se pokud to tak vypadá... prostě sem jen chtěl prezentovat svuj názor na Slackware a ten takový je, s tím nic nenadělám.

[jm]

Eh, sem si to teď po sobě ještě jednou přečetl a koukam že by z toho mohl být dost drsný flejm

Ale ne, proste balickovaci system neresici zavislosti je "broken by design", no a v tech oficialnich repositarich je fakt houby. To je pak pekne, kdyz kolega o neco vyse napise, ze za rozbite neoficialni balicky si muze uzivatel sam, no a co ma teda pouzivat?

No nic, Keep Gentooin'...

[Bubak]

To nebyl můj cíl, omlouvám se pokud to tak vypadá...

Mas stesti. Nechapu, proc by mel byt Slack na desktopu masochismus. System jednou nainstaluju, dam si trosku prace s tim, aby vypadal a choval se tak, jak potrebuji a jake mam dalsi starosti?

[Michal Vyskočil]

Jediné co se mi na Slackwaru líbí je jeho čistota a jednoduchost

Čistota a jednoduchost jsou pojmy, pod kterými si nedokážu nic představit. Rozhodně ne u Slackware, kde se init skripty nastavují jejich editací . Vyzkoušel jsem spoustu distribucí a nějak nevím, v čem by mělo být Gentoo čistější, než CentOS. Je pravda, že je /etc/conf.d/ přehlednější, než /etc/sysconfig/. Nicméně, pokud se člověk naučí příkaz pro přidání/odebrání služby do runlevelu, nebo její spuštění, což je místo, kde se distribuce liší nejvíce, není nejmenší problém.

BTW: člověk se nesmí dívat do /etc/rc*.d/