Dotaz: Jak se vlastne instaluji programy v DE?

[petrfm]

Ahoj, pouzivam KDE - Kubuntu a tak nejak jsem nad tim jeste nepremyslel. Prechazel jsem z win, kde je to jasne, program se bud nainstaluje a vytvori si zastupce ve start nabidce, nebo je mozne, vytvorit si zastupce rucne a vlozit je do start nabidky, plochu, atd.

Jak to ma linux, na to teprve postupne prichazim. Pokud stahnu SW s balickem, tak se vetsinou udela vsechno samo, pak jsou tu ale SW postavene treba na JAVE, ktere maji jen .jar soubor a spoustec napr. .sh, ktery jen spusti Javu + konretni JAR. Muzu si vytvorit odkaz na ten spousteci skript a soupnout si ho "na plochu", nebo pres nabidku do "Spoustece aplikaci", coz je obdoba Start nabidky z win.

Chci se jenom zeptat, jestli to takhle delam dobre a jak to delaji ty instalacni balicky? Kam to pridavaji, ze se treba po napsani prvnich par znaku aplikace objevi Spustit xyz. Existuji v linuxu nejaka obecna pravidla, ktera funguji napric distribucemi a treba i DE?

Snad muj dotaz pochopite, zni to asi zmatecne, ale to je tim, ze vlastne sam nevim, jestli si odkazy na SW pridavam spravne. Trochu mne ta volnost na linuxu nekdy desi Treba i v tom, ze nema Program Files a programy tak muzu nahravat v podstate kamkoliv. Stejne tak mne trochu mate, ze i balicky se instaluji do ruznch adresaru, ze neni nic jednotneho a je pak trapeni to hledat a mit v tom poradek. Aspon pro mne

P.

---

---

Odpovědi

[MadCatX]

Slušnější aplikace si do /usr/share/applications nebo ~/.local/share/applications přidají .desktop soubor, který může vypadat třeba takhle

[Desktop Entry]
Type=Application
Version=1.0
GenericName=File Synchronizer
Name=MEGASync
Comment=Easy automated syncing between your computers and your MEGA cloud drive.
TryExec=megasync
Exec=megasync
Icon=mega
Terminal=false
Categories=Network;System;
StartupNotify=false
X-GNOME-Autostart-Delay=60

X-Desktop-File-Install-Version=0.22

DE nástroje, co vytváří menu se spouštěči aplikací si ten adresář projdou a z nalezených .desktop souborů menu sestaví.

[nobody]

polozky menu, ikony na plose, panelu, apletu jsou definovany jako soubory .desktop

# pro celej system (zde se vytvari/kopiruji pri instalaci balicku)
/usr/share/application

# pro uzivatele (zde se vytvari kdyz pridas do spoustece)
$HOME/.local/share/applications/

# pro uzivatele na plose
$HOME/Plocha

Linux sice nema Program Files, ale ma ruzne standard cesty kam se ve vychozim nahrava (specialita je pak /opt ktere ma nejbliz k ProramFiles, ale pouziva si minimalne), normalne si aplikace proste nainstaluje ruzne casti na patricna mista... system nastaveni do /etc, systemove knihovny do /lib, vetsinu pak rozprostre v /usr do lib,share,doc,man,locale,icons...

Chapu ze je to z prvu tezke pochopit ten poradek a system kterej v tom je, kdyz si zvyklej ze Widle meli totalni bordel kterej se jako poradek jenom tvaril... Pro zacatek si jen uvedom ze se o to nemusis starat, postara se o to spravce balicku :)

# dohledani kteremu balicku patri konkretni soubor
dpkg-query -S jmeno_souboru

# zobrazeni vsech souboru patrici konkretnimu baliku
dpkg-query -L jmeno_baliku

[lertimir]

Ještě pár slov pro doplnění. Naprostá většina programů se nainstaluje do jednoho z adresářů /bin, /sbin, /usr/bin, /usr/sbin. Ty bin jsou pro běžného uživatele a sbin jsou pro superuživatele a někdy je ani obyčejný uživatel nemá v cestě. Dělení na něco přímo v kořeni a něco v /usr má historický původ v unixu z doby, kdy /usr se mountovalo jako samostatný FS a někdy i jen RO FS a přibližně odráží to, že přímo v bin jsou více low level utility a v /usr/bin více high level utility a programy, se systémem něco mělo jít dělat i když se nepřimoutnul /usr. Knihovny si programy nasázejí do /lib /lib64 /usr/lib /usr/lib64. Když jsou zdrojáky tak jsou v /src /usr/src. Mnoho baliku si naskládá i dost informací do /usr/share. a některé mají průběžná data ve /var/lib (a samozřejmě konfiguace v /etc) kde je .desktop byla řeč.

Instalační package má popis, co má udělat, a kusy naskádá na správná místa a při odinstalaci je zase posbírá a smaže. strom /opt se používá poměrně hodně, ale hlavně pro uzavřený soft. Uzavřený soft si obvykle vše potřebné včetně knihoven přiveze sám a naskládá si to do právě zmíněného /opt. To že si vozí mnohdy knihovny, je podle mne proto, že i když linuxové API je dost stabilní, není to stabilita na 100%, protože by to omezovalo možný vývoj. Platí pravidlo, že když už něco vývojáři změní, tak musí změnit i to, co na změně závisí. Jenže do uzavřeného softu změnu nemohou promítnout a na druhou stranu se uzavřený soft nemůže 100% spolehnout na stabilitu knihoven, tak si přiveze svoje knihovny v dané přislušné funkční verzi. Přiklady: googleearth, chrome, SAS, Oracle database

[Plamen]

Tady bych si dovolil zmínit pro začátečníka možná lépe uchopitelný prostředek: http://packages.ubuntu.com/. Tam se nechá zjistit spousta věcí o balíčcích napříč distribucemi, tedy nemusím to mít ani nainstalované a zjistím, ke kterému balíku patří tento soubor v té které verzi Ubuntu. A zjistím třeba, že mi tam ten balík visí po nějakém upgrade z minulosti. Používám Debianí obdobu této stránky a nemohu si ji vynachválit.

[Plamen]

Ehm ... moje reakce je na použití dpkg-query, teď tedy vidím nade mnou komentář, který jsem přehlédl, když si teď prohlížím vzniklý strom odpovědí, není to na první pohled jasné, tak to pro úplnost dopisuji.

[nobody]

Takže když si chceš uklidit po balíku brasero, třeba, stačí ti. sudo rm -rf /usr/{bin,lib,share}/brasero Když to z nějakých příčin balíčkovač nebude schopný už smazat?

Zatímco widláci musí smazat jen celou složku brasero, pokud nemá spouštěč uninstall?

[nobody]

vlastnost "z nejakych pricin" ma patentovanou microsoft... nicmene kdyz bych chtel smazat rucne seznam vsech souboru prectu ho z /var/lib/dpkg/info/brasero.list, ve windows ho nezjistim nikde...

widlaci v kdyz smazou slozku brazero, tak jim zustane bordel v nekolika slozkach v users, v system32, ruzne vetve v registru, zaregistrovane dll, po restartu widle zacnou rvat ze je neexistujicii objekt

[pavlix]

users -> $HOME/., system32 -> info v registrech s uvedenou cestou, registry -> nepodstatná velikost záznamu. Stačí smáznout záznam z registrů, třeba pomocí $MS nástroje Autorun.

[nobody]

Chapu ze je to z prvu tezke pochopit ten poradek a system kterej v tom je, kdyz si zvyklej ze Widle meli totalni bordel kterej se jako poradek jenom tvaril... Pro zacatek si jen uvedom ze se o to nemusis starat, postara se o to spravce balicku :)

V těch widlích si to může uživatel změnit kam to chce, jen ti nesvéprávní musí být vedeni balíčkovačem, který to změnit neumí, jsem chtěl říct.

[nobody]

ve widlich si to uzivatel zmenit nemuze krome prgdir, ale stejne neco bez jeho vlivu leze do common,appdata,users,system,system32, dllka se duplikujou v prgdir nebo sdilej nebo prepisujou, nikdy nevis co, je to zprasene a bez logiky... jen naiva si muze myslet ze zmenou v instaleru ciloveho diru nasmerujou do toho diru celou instalaci :)

pokud budu chtit byt prase jako ty ve windows, stahnu si balik rucne a pak pouziju dpkg --instdir=/sem/to/chci --install balik.deb

btw: ve WindowsPhone si stahujes aplikace rucne z webu a instalujes si je rucne nebo pouzijes balickovac ? ;)

[tacoberu]

Možná jsem nesvéprávný (přeci jen jsem jen vývojář), ale já se nechci starat o to, kam všude se má jakej soft instalovat. Ve výsledku je mi upřímně jedno, jestli se mi firefox instaluje do "Program Files", nebo do /usr/bin. Protože pro mě je důležitý, abych si mohl najít potřebné informace, který mne zajímají. A vítám, pokud se software instaluje, odinstalovává, aktualizuje sám.

@nobody: To se pokoušíš o nějaký flamewar, nebo tyto názory opravdu máš?

[lertimir]

Až na to, že to není 100% spolehlivost. Pokud jsi skutečně vývojář, tak by sis měl lehce představit dvě situace. Jednak že při vývoji se na něco zapomene, něco si tvůrce nevšimne apod. Napřiklad že program při běhu vyvoří další soubory/adresáře jako součást svého normálního provozu a odinstalace udělá jen odinstalaci toho, co nainstalovala. A za druhé uživatel to nainstaluje a spustí nějakým zcela nečekaným způsobem.

Pokud nemáš přehled, co se v systému děje, dospěje systém po čase k tomu, co důvěrně znají uživatelé Win, rozvrtá se to natolik, že přeinstalace je jediná cesta, jak to dát dohromady. V linuxu se systém rozbordelí mnohem méně a je to tím, že všichni nebo alespoň balíčkovači v distribucích hierarchii drží. Proto, že ve Win mnoho programů po sobě neuklízí při odinstalaci vznikly Instalatory a odinstalátory, které celou instalaci a mnohdy i s prvním během programu spouští pod sebou a v podstatě vytvářejí log toho kam bylo sáhnuto a jsou schopny (ne úplně vždy) akce vzít poslat zpět.

[tacoberu]

Na stoprocentní spolehlivost si nikdo nikde nehraje. I databázi splňující ACID lze rozbít (= uvést do nekonzistentního stavu). Pokud jsem nucen přeinstalovat systém jednou za rok, je to lepší, než jednou za půl roku. (Fedoru zatím přeinstalovávám se změnou hw, a to jsem docela dobytek.)

Pointa mého příspěvku byla, že já nechci mít přehled o tom, co se v systému děje. (Ne, že bych neměl, ale nechci.) Očekávám, že programy budou dělat většinu mé rutinní práce, a já se můžu soustředit na svou práci.

Požadovat od uživatele znalost systému je architektonicky špatně.

PS: Pokud to co popisuješ se na windows opravdu děje, tak to potěš koště.

[tacoberu]

IMHO smůla Windows byl v tom, že největší boom měl v dobách, kdy neměl správce software, tudíž nemohl vývojáře nijak hlídat. A pak se dostal do bahna zpětné kompatability. V Linuxu, s jeho balíčky je situace přeci jen lepší, i když je zde ještě velký prostor ke zlepšování.

[tacoberu]

A za druhé uživatel to nainstaluje a spustí nějakým zcela nečekaným způsobem.

Toto si pochopitelně představit nedokážu (protože tautologie).

Faktem je, že balíčkovací systém dost dobře umožňuje instalovat jen konkrétním a konktrolovaným způsobem. Cokoliv jiného (například rozbalení balíčku a ruční překopírování) odmítám nazvat instalací.

Spustit aplikaci lze také jen určitým způsobem.

Schválně, a to nemyslím ironicky, zda by si mě byl schopen překvapit nějakým scénářem.

[nobody]

ten nobody co se vydaval za me (i za pavlixe) a psal s diakritikou se pokousel o flame, zadne nazory nema a ve svem telefonu jiste pouziva balickovac take :)

[Filip Jirsák]

Já bych to vzal ještě o krok zpět. Linux obvykle používáte jako nějakou linuxovou distribuci. A drtivá většina distribucí má nějaký svůj balíčkovací systém, a v systému máte nainstalován správce balíčků. Software se pak primárně instaluje tak, že jej vyhledáte ve správci balíčků a nainstalujete přes něj. Instalovat software tak, že odněkud něco stáhnete, to byste měl dělat pouze v opravdu dobře odůvodněných případech. On se ten správce balíčků stará například o to, že když je vydán balíček s novou verzí, informuje vás o tom a nabídne aktualizaci. Když si software stáhnete někde z internetu, musíte si aktualizace hlídat sám. Balíčkovací systémy mají i další výhody, ale ty aktualizace jsou dnes asi nejdůležitější.

Takže dobře ten váš postup není, pokud to jde, používejte distribuční správce balíčků. Pak s tím ani nebudete mít trápení a budete v tom mít pořádek.

Jak je to se spouštěči aplikací už napsali ostatní.

[rastos]

Odporúčam pozrieť sa na xdg-desktop-icon či xdg-desktop-menu.

[Plamen]

Ohledně toho, kde se soubory nacházejí - viz FHS, jako startovací bod doporučuji nastudovat Filesystem Hierarchy Standard, dále lze využít nějaký vyhledávač, třeba Google s výrazem "FHS Ubuntu", případně "FHS Debian" a jako vyšší level následně například informace o tom, jak se vytvářejí v Debianu/Ubuntu balíčky (Ubuntu vzniklo z Debianu, balíčkovací systémy fungují na stejném principu). Základy zde již řekli předchozí přispěvatelé, ale zvídavý příchozí z prostředí Windows (což jsem byl v roce 1996 koneckonců i já) jistě dokáže postupně vstřebat vše potřebné, aby pochopil jak se věci mají. A k čemu a jak slouží proměnná PATH. Ta dle mého fungovala dobře v DOSu, ale spolu s "Program Files" dle mého ve Windows ztratila význam.

P.

[petrfm]

Diky panove, moc jste mi pomohli. Tusil jsem, ze existuji nejake takove standardizovane soubory, se kterymi pak system pracuje, aby to mohlo fungovat i napric distribucemi.

Jinak balickovaci system je mi znam, ale pouzivam i exoticke veci, jako treba rizeni CNC frezky, ruzne male udelatka pro HW desky a to vetsinou nikdo do repozitaru nedava, ale stahuje se to normalne z GITU, nebo webu tvurce. Pak je mozne to placnout do adresare a spoustet klikem, ale ja bych si je rad pridal mezi programy, nebo "udelal ikonu" (stary windowsovsky zvyk )) ) a nevedel jsem, jestli do delam "dobre", rad bych ziskal spravne navyky a neprasil to

Trochu se totiz hrozim toho, az vyjde nova verze meho stable kubuntu a budu muset svuj desktop aktualizovat. OK, to jde relativne i samo, ale pokud budu menit stroj, asi mne nemine cista instalace a potom dohrani stareho SW a tady se hodi, vedet, kde ty programky vlastne mam a moci si je jednoduse prenest na novy system. Ve WIN jsem se za ty roky orientoval, takze jsem vedel, jake slozky zalohovat a pak nakopirovat, ale v linuxu jsem stale naprosty zelenac, co se uci za pochodu.

P.

[KOLEGA]

[OFFTOPIC] Teda člověče, takhle uvědomělýho uživatele už jsem dlouho neviděl ... Přijde k tomu s pokorou, apod. palec nahoru [/OFFTOPIC]

[Pavel 'TIGER' Růžička]

Ono to možná není ani tak o uvědomění, jako o člověku takovém. Pokud má rád někdo pořádek, a přesnost, tak proč by měl mít v počítači bordel? pochopitelně to funguje i obráceně. Podle toho, v jakém stavu má člověk počítač si uděláš obrázek o tom, jaký ten člověk je.

[petrfm]

Presne tak. Ja mel kdysi v pc velky bordel, ale kdyz mas tech pocitacu vice a parkrat po letech reinstalujes, zjistis, ze co neudelas dneska, budes muset resit potom a pripravi te to o 2x tolik casu. Proc teda uz kdyz instaluju desktop, si nedat trochu prace s tim, abych vubec vedel, co v nem mam. Kor u systemu, ktery jeste tak neznam, to se potom vyplati dvojnasob, respektovat rady a zasady, nez potom neco dlouze hledat.

[lertimir]

Doporučil bych, všechny takto vytvořené specifické programy vkládat v /opt do samostatných adresářů jednotlivých projektů. Nebude se to plest to standardní struktury systému. Pokud jsou programy standardně vytvářeny a mají ve skriptech rozdělní do bin, lib, src, atd. je ještě jedno vhodné místo a to /usr/local což je určeno pro uživatelsky doinstalovaných programů, které mají standardní rozdělení. Pokud chceš ikony, a možné jednoduché spouštění z příkazové řádky, tak zařazení softlinků buď do ~/bin nebo /usr/bin.

[tacoberu]

Já bych se vytváření balíčků tolik nebál. Není to zas tak složité. A získáš benefit v podobě bezešvého zakomponování do systému.

Krom již zmíněného /opt adresáře ještě existuje možnost čistě uživatelské instalace, kdy se to cpe do do ~/.local Nejsem si tedy jist, nakolik je to standardní, ale na takové ty programy stažené z webu to používám.

[Josef Kufner]

~/.local je dobrá volba na věci, které máš pro sebe a ostatních uživatelů se to netýká, nebo pokud nemáš roota.

[tacoberu]

Je ~/.local ve standardech?

A je ve standardech /opt? Subjektivně mi to přijde jako taková prasárnička.

[Josef Kufner]

/opt standardizované je. Jak je na tom ~/.local nevím, ale spolu s ~/.config někde popsané také bude.

[petrfm]

Budu asi pouzivat /opt, protoze jsem se o tom docetl vsude, ze je to takovy standard. Sice pocitace pouzivam sam, ale i tak. Jednoduse se to pamatuje, ja mam spatnou pamet a uz zitra si nebudu pamatovat nejake /home/petr/.local ))

V tom mne linux hodne trapi, mam fotografickou pamet a nazvy si vubec, ale vubec nepamatuju, takze ja si musim zapamatovat, kde zhruba to ve stromove strukture bylo, nebo si psat poznamky

To, co dva dny nepouziju, treti den nevim. Jeste ze ma na syntaxe konzole man, jinak bych byl uplne v (_!_)

[pavlix]

Rozhodovat se mezi /opt a ~/.local podle nějakých standardů je nesmysl. Buď to chceš na úrovni systému a dáš to mimo ~, nebo to chceš na úrovni uživatele a dáš to někam do ~.

[lertimir]

/opt samozřejmě v FHS je. včetně opt podadresářů v /etc /var atd.

[tacoberu]

Škoda.

[nobody]

az vyjde nova verze meho stable kubuntu
v klidu, mas jeste par let :)
ale pokud budu menit stroj, asi mne nemine cista instalace neni potreba, s GNU/Linux neni problem vzit HDD a strcit do naprosto odlisneho HW, normalne nastartuje a nepoznas rozdil :) (za predpokladu ze by HW podporovala cista instalace) nevadi ani zmena IDE<->SATA...

narozdil od Windows ktere maji databazi aktualnich zarizeni a k nemu nainstalovane ovladace a pri zmene cehokoliv (i usb portu kam strcis) doinstalovava/odinstalovava... Linux se pri startu podiva na cem bezi a aktivuje prislusne jaderne moduly (~ovladace - nainstalovane jsou vsechny), provadi se to normalne pri kazdem startu :)

[Josef Kufner]

Tak, tak. Zrovna teďka jsem takle naklonoval starý notebook na nový. Stačilo udělat minimální instalaci Debianu, aby mi to nabootovalo do něčeho použitelného, a pak jsem tu minimální instalaci po síti přeplácnul starým systémem. Jen to chtělo změnit hostname, upravit /etc/fstab a pohrát si s novým Grubem.

[petrfm]

Tak to je fantazie, to mne nanapadlo Jen se zeptam - kdybych vyndal disk a strcil ho do USB - SATA redukce, pak bych provedl bitovou kopii, tak bych ani zadny Grub apod. nemusel resit, je to tak?

[Josef Kufner]

Pokud bys zrovna nepřecházel z MBR na UEFI, tak by to fungovalo. Také ale cílový disk musí být stejně velký nebo větší (u většího pak musíš zvětšit partition a filesystém na ní). Pokud máš disk šifrovaný (tedy root a swap v LVM a to celé v šifrovaném oddílu), je zvětšování už docela netriviální operace, takže je jednodušší si to rozdělit znovu pomocí instalátoru.

[lertimir]

To záleží na některých detailech, ale změn není mnoho. Typicky fstab a nastavení grubu závisí buď na UUID

cat /etc/fstab
UUID=318424ab-b633-454e-8d04-b0c0c551d9f1 / btrfs defaults 0 0
UUID=7557c884-0876-4e7f-82be-7e93721568fb /boot ext4 acl,user_xattr 1 2

nebo na ID

cat /etc/fstab
/dev/system/root        /       ext4    noatime,acl,user_xattr,discard 1 1 
/dev/disk/by-id/ata-OCZ-AGILITY3_OCZ-3W17E1197QC92G7L-part2     /boot   ext4    noatime,acl,user_xattr,discard 1 2 
/dev/disk/by-id/ata-ST3000DM001-1CH166_Z1F22WNJ-part1  swap    swap    defaults 0 0 

UUID se snad překopíruje (nikdy jsem to netestoval), ale ID jsou Typy a reálná seriová čísla disků, takže jsou jedinečná. Na druhou stranu zase to dává naprostou jedinečnost toho, že když měním disky v kompu, tak vždy vím přesně, co a odkud se připojuje. Podobně i grub může být vázán na UUID nebo ID.

[petrfm]

Vidis, to mne vubec nenapadlo. Nebude tech parametru vice, ktere jsou nekde zapsany a muzou pak vyzadovat zmeny? Napada mne treba MAC adresa, apod.

[nobody]

spravne :) dle mac sitovek je pri prvnim pouziti generovano udev pravidlo ktere pak zaridi ze se nebudou po restartu prehazovat prirazene nazvy jako eth0, eth1 atd... nechat puvodni pri zmene hw by nemelo delat problem na desktopu, kterej ma nastaveno dhcp na vsechna rozhradi pres network-manager (problem to je/muze_byt na serveru kde mas statickou ip a pozadujes eth0 pro konkretni lan)

kazdopadne je v to souboru /etc/udev/rules.d/70-persistent-net.rules, muzes tam zamenit rucne MAC sitovky(ek) v novem HW, nebo soubor smazat a vytvori se po restartu znovu uz pro aktualni MAC

btw: pokud bys pouzil pro klonovani disku clonezilla, tak o zmenu uuid v fstab/grub, mac v *net.rules se postara sama

[pavlix]

Doporučuju si vytvořit ty balíčky a pokud je toho víc, tak nějaký skript, který to celé zautomatizuje.