Portál AbcLinuxu, 12. června 2024 11:16
4.2.2009 20:19
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
, ale na ten se nepráš. Takže za mě volím DEB
5.2.2009 11:17
Jakub Lucký | skóre: 40
| Praha
5.2.2009 16:27
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
určitě se to dá. Různou kombinací aptitude upgrade, dist-upgrade, install -f, odinstalací balíčků a podobně ... je to porod, ale většinou se povede.
můžete mi vysvětlit proč je rozbitý systém závislostí s DEB problém?
Je to proto, že APT není nijak zvlášť výkoný solver? Zazněl tady názor, že u RPM to takový problém nebývá, což mě vede k doměnce, že systém APT/DEB staví na perfektní propracovanosti vztahů mezi balíky a kdžy se něco pohnojí tak neví co s tím.
5.2.2009 21:48
Jakub Lucký | skóre: 40
| Praha
A proč je to problém pro Apt to vyřešit? Já to zažil asi 3x u rpm a solver mi dal na výběr jak to chci řešit, a prostě to dal dokupy. moc nerozumím tomu, jak seto může"rozbít" do stavu, že to nejde opravit.
5.2.2009 22:51
Jakub Lucký | skóre: 40
| Praha
problém bude v tom, že DeltaRPM používá IMHO pouze Suse a to jenom pro balíky z repozitáře "updates". Takže se jedná o tak málo dat, že je to výhoda jen na papíře.
4.2.2009 20:48
Jardík | skóre: 40
| blog: jarda_bloguje
Většinou se závisí na jaderných symbolech u kernelových modulů, nebo na nějakých so souborech v případě normálních binárek. Zbytek závislostí nebývá většinou registrován automaticky. Nehledě na to, že se automatická registrace závislostí dá úplně vypnout
a proč teda řešení závisostí v opensuse je tak náročné a tahá s takové obrovské kvantum dat? Apt co se týče schopností řešit asi nebude žádná sláva, ale když se podívám na debian, tak se z internetu stahuje úplné minium. IMHO na Apt nejsou kladeny žádné výkonostní nároky, a velmi mu poháhá koncepce DEB balíků a repozitářů.
to je vše?
4.2.2009 22:48
Jardík | skóre: 40
| blog: jarda_bloguje
6.2.2009 02:28
Jardík | skóre: 40
| blog: jarda_bloguje
problém bude v tom, že DeltaRPM používá IMHO pouze Suse a to jenom pro balíky z repozitáře "updates". Takže se jedná o tak málo dat, že je to výhoda jen na papíře.
můžu mít OT:
Co používáš na serveru (pokud nějaký máš) ?
No testuju pro svůj komunitní server různé distribuce a rozhoduju se co na to nasadím. Zatím mi na každé něco nesedí. Co za verzi Opensuse tam máš a jsou nějaké problémy se serverovým nasazením?
používáš dm RAID? a které partitions?
6.2.2009 13:23
David Šmíd | skóre: 10
| blog: dsmid
DM raid ? Proboha proč ? To je jenom zoufalý způsob, jak se dostat k datům na Windows-only fake RAIDu.
Proč nepoužít léty ověřený softwarový RAID (md) ?
ebuild ......
Radsi nepouzivam distribuci rizene zavislosti.... nikdy jsem s nimi nesouhlasil a veskery soft si kontroluju podle sveho.... (ale je pravda ze instaluju jen na jeden pocitac)
Kdy už vám dojde, že je úplně jedno, jestli to je DEB nebo RPM, že záleží jenom na tom, jestli se ten balík udělá dobře nebo špatně ?
Ani RPM, ani DEB nechybí žádná kritická vlastnost, která by zabraňovala vytvořit dobrý balíček, který bude radost instalovat. Já používám RPM distribuci, vytvářím RPM balíky, s DEB moc zkušeností nemám, ale nedovolil bych si tvrdit, že je horší než RPM. Je prostě jiný.
Nezáleží na tom čím se to udělá, ale jak se to udělá.
Mě šlo spíše o stav, kdy RPM má spoustu repozitářů, a když si jich člověk přidá tolik kolik potřebuje, tak jsou mnohdy v konfliktu. DEB mívá jeden velký a občas nějaký doplněk.
Ale to nemá nic společného s RPM nebo DEB. Moje distro třeba používá RPM a má jeden jediný repozitář s různými sekcemi.
Určitě existují i DEB distribuce, které mají spoustu repozitářů. Nezáleží na formátu balíčků, záleží na distribuci.
Máte naprostou pravdu. Formát balíčku je podružná záležitost, důležitá je *kvalita* balíčků (aktuálnost balíčků, závislosti, patch politika, možnost paticipace, build service, contrib repoziáře, korektní popisky, smyslupné pojmenovávání a třídění,..).
Já bych si dokonce dovolil tvrdit, že rpm a deb svými vlastnostmi z pohledu uživatele moc neliší. Pravda, deb má například suggested packages (něco jako nepovinné závislosti) ale to by asi nebyl problém doimplementovat do rpm a tak to bude podobně s osotatními drobnými featurami.
Skoro zbytečný luxus mít dva tak velmi podobné formáty pro binární distribuce.
Pravda, deb má například suggested packages (něco jako nepovinné závislosti) ale to by asi nebyl problém doimplementovat do rpm a tak to bude podobně s osotatními drobnými featurami.Ale to v RPM je samozřejmě také... minimálně v tom susím.
Vida jak se to vše vyvíjí že to ani nestačí jeden sledovat! Jakou verzi RPM má Suse? 4.x nebo 5? Podporuje tuhle vlastnost nějaký klient, Yast? Něco ve smyslu kliknu na balíček A a nabídne mi to, že by možná bylo přínosné nainstalovat i B, C a D ať si vyberu které? Synaptic a Apt (pro RPM) tedy ne (PCLinux a hádám ani Mandriva).
marek@ww010757:~> rpm -qv rpm rpm-4.4.2.3-20.3 marek@ww010757:~>
apt v PCLOSu navrhované balíčky nabídne (zmíní se o nich), v Synapticu je volba "Instalovat automaticky navrhované balíky", ale aby to bylo funkční, musel jsem ho trochu upravit.
Jiná věc je, že v repozitáři není jediný balíček, který by obsahoval tagy "Suggests" nebo "Recommends".
Když je tu už taková pěkná diskuze o balíčcích, tak se zeptám. Používám Ubuntu a když si nainstaluji nějaký program, tak si zjistí podle závislostí, co je zapotřebí a nainstaluje to. Problém je v odinstalování. Odinstaluje se jen program, ale ostatní knihovny (které už nepotřebuju) tam zůstávají. Dá se s tím něco dělat?
autoremove
autoremove is used to remove packages that were automatically installed to satisfy dependencies for some package and that
are no more needed.
deborphan, viz uryvek z jeho man stranky:
deborphan finds packages that have no packages depending on them. The default operation is to search only within the libs and oldlibs sections to hunt down unused libraries.Vetsinou staci pouzit
apt-get delete `deborphan` a je to.
remove, ne delete
5.2.2009 12:39
Jakub Lucký | skóre: 40
| Praha
dpkg -l | awk '$1 == "rc" {print $2 " purge"}' | dpkg --set-selections
Samozřejmě
Jestli jsem to správně pochopil tak vy i někteří komentátoři vyzdvyhujete minimalistické závislosti jako výhodu. Opravdu je tomu tak?
Ponechám stranou technicky nesprávné tvrzení, že samotný deb systém nějak ovlivňuje jestli bude mít bohaté nebo minimalistické závislosti, budu to číst jako „správci repozitářů distibucí založených na systému DEB inklinují spíše k minimalistickým závislostem“ s tímto výrokem už souhlasit lze.
A teď k pointě. Minimalistické závislosti ale nemusí být výhodou! Příklad z nedávné
Updatoval jsem u kamaráda nedávno jeho Knoppix, což je distribuce založená na deb a používající balíčky z Debianu. Nebyl čas updatovat všechno hromadně, tak jsem zvolil jen pár balíčků co jsme v tu chvíli potřebovali, mezi nimi i udev a dbus. Bohužel jsem zapomněl na hal. Po rebootu okamžitě pád do příkazové řádky, skoro nic nenaběhlo, zejména ne desktop a internet. Stará verze halu zjevně nespolupracovala s novějším udev a-nebo dbus. Užil jsem si pernou hodinu vzpomínání na ruční příkazy k nahození wireless internetu a práce s apt. Pak ještě ten detail najít co to vlastně způsobilo, naštěstí jak mnoholetý uživatel internetu mě hal napadl poměrně záhy. Pro začátečníka nebo méně poročilého by tohle byl konec a linux by se asi stěhoval z disku úplně.
Nevím, jestli to byl jen bug Knoppixu a tu závislost tam jen zapoměli, chyba se může stát každému v každé distribuci, ale po zběžném prozkoumání několika dalších balíčků Knoppixu bych skoro řekl, že je to projev systematické politiky této distribuce.
Závislosti mají být hlavně *správně*, tj. všechny potřebné aby se neopakovala situace výše popsaná.
Osobně zastávám názor, že raději o něco víc než míň, v dnešní době disků o stovkách GB nemá cenu meditovat nad několika možná zbytečně ztacenými MB. Můj čas je mnohem dražší než místo na mém disku. Programy i tak zaberou jen zlomek toho co data, zvlášť pokud pracujete s fotkami nebo videem.
5.2.2009 18:50
Jakub Lucký | skóre: 40
| Praha
Nebyl čas updatovat všechno hromadně, tak jsem zvolil jen pár balíčků co jsme v tu chvíli potřebovali, mezi nimi i udev a dbus. Bohužel jsem zapomněl na hal.Tak tohle je pochopitelně bug... Pokud daná aplikace nefunguje se svými závislostmi, pak je problém u maintainera... Pokud to takhle Knoppix dělá všude, tak Debian ne...
5.2.2009 20:17
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
A co klasika tar.gz, tar.bz2, ...?
V poslední době narážím u některých aplikací na problém, že jejich zdrojové kódy jsou poskytovány pouze jako zdrojový rpm nebo deb balíček. Klasika jako tar.gz je zcela ignorována. Proč si mám doinstalovávat rpm, deb nebo další pomocné nástroje jenom proto, abych se dostal ke zdrojovým kódům? Samozřejmě to platí i u binárních archivů. Závislosti může pohlídat nejenom rpm nebo deb. Například sorcery.
Je to od nich ošklivé, ale v SRPM ten tar.gz uvnitř nakonec je, a aby ses k němu dostal, postačí ti jednoduchá utilitka jako rpm2cpio. I tak je to opruz, ale kdyby všechno mělo takhle jednoduché řešení ...
jako zdrojový rpm nebo deb balíček. Klasika jako tar.gz je zcela ignorována.Jen pro zajímavost. Co je poskytováno pouze jako zdrojový rpm, nebo deb balíček? Tu první variantu si dokážu představit, protože rpm2cpio je potřeba, ale u zdrojového Debianího balíčku snad žádné zpeciální nástroje potřeba nejsou, ne?
Co je poskytováno pouze jako zdrojový rpm, nebo deb balíček?Zdrojový DEB balíček? To někdo na světě používá? Debian odjakživa zdrojáky distribuuje jako .tar.gz + diff + dsc.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.