Ubuntu 22.04 a repozitáře

24.8.2022 22:22 | Přečteno: 2792× | blogísek | poslední úprava: 24.8.2022 23:23

Několik poznámek k repozitářům třetích stran na *ubuntu 22.04 Jammy Jellyfish: nahrazení Firefoxu ze snapu a prioritizace PPA, další repozitáře, klíče.

První věc, kterou už dlouho dělám, je zakaz instalace doporučovaných a navrhovaných balíčků jako závislostí. Trochu (a někdy, jako u T_EXu, hodně) to šetří objemy stahovaných a ukládaných dat.

soubor /etc/apt/apt.conf

APT::Install-Recommends "false";
APT::Install-Suggests "false";

Chápu, že Canonicalu se snap hodí na Ubuntu Core, ale nepoužívám Ubuntu Core. Četl jsem, proč je Firefox na Ubuntu implicitně distribuován jako snap, ale nelíbí se mi to, např. protože navzdory všem optimalizacím (až po vydání 22.04) je na slabším hardwaru studený start pořád pomalý a z podstaty o moc lepší už to být nemůže.

Můj preferovaný postup pro odstranění snapu a instalaci Firefoxu z PPA mozillateam/ppa je ten z DebugPointu.

Jelikož používám ještě repozitář XtraDeb, který také obsahuje balíčky Firefoxu, je potřeba se pojistit, aby se místo oficiálního PPA do systému necpaly tyto.

soubor /etc/apt/preferences.d/xtradeb-ubuntu-apps (protože záznam repozitáře v /etc/apt/sources.list.d/ je xtradeb-ubuntu-apps.list):

Package: firefox*
Pin: release o=LP-PPA-xtradeb-apps
Pin-Priority: -1

Krátce jsem zkoušel Pop!_OS. Některé věci se mi na něm líbily, jiné ne. Každopádně jeho repozitáře si lze přidat i přímo do Ubuntu. Varuji, že release nebo staging systém při aktualizaci předělají na Pop!_OS. Nicméně proprietary se může hodit: obsahuje např. klienty pro Discord a Slack, dále Google Chrome a nějaké další aplikace (nebo CUDA), aniž by byl potřeba flatpak či snap.

Drobný problém je ale s klíči. Instrukce k řadě repozitářů stále používají zastaralý příkaz apt-key, který klíče stahuje do adresáře /etc/apt/trusted.gpg.d, při jehož použití si APT stěžuje. Např. WineHQ nyní doporučuje stažení klíče pomocí wget do adresáře /usr/share/keyrings/, nebo jde použít napřímo gpg --no-default-keyring --keyring <cesta> … místo dosavadního apt-key adv.

# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 63C46DF0140D738961429F4E204DD8AEC33A7AFF
gpg --no-default-keyring --keyring /usr/share/keyrings/pop-os-archive-keyring.gpg --keyserver keyserver.ubuntu.com --recv-keys 63C46DF0140D738961429F4E204DD8AEC33A7AFF

Do záznamu repozitáře v /etc/apt/sources.list.d pak přijde navíc cesta ke klíči, např. /etc/apt/sources.list.d/pop-os-proprietary-jammy.list:

deb [signed-by=/usr/share/keyrings/popos-archive-keyring.gpg] http://apt.pop-os.org/proprietary jammy main

Všeho všudy používám aspoň čtyři PPA – kelleyk/emacs (novější Emacs), kubuntu-ppa/backports (novější KDE*), mozillateam/ppa (Firefox a Thunderbird), unit193/encryption (VeraCrypt) – a zmiňované Pop!_OS proprietary, WineHQ, XtraDeb… a pak už jen pár nahodilých aplikací.

Přidávat je na každém systému zvlášť je opruz, takže někdy prostě přenáším adresáře /etc/apt/sources.list.d/, /etc/apt/trusted.gpg.d/ a /usr/share/keyrings/, příp. zmíněné /etc/apt/preferences.d/ atd.

       

Komentáře

[k3dAR]

apt-key, který klíče stahuje do adresáře /etc/apt/trusted.gpg.d, při jehož použití si APT stěžuje.

nestezuje si kdyz je klic (samostatne) v adresari /etc/apt/trusted.gpg.d/, ale kdyz je sloucene v souboru /etc/apt/trusted.gpg

[Max]

Zajímavé. Nepřemýšlel jsi někdy třeba o Archu? Jedeš rollup, jedno repo, když něco chybí, je to na 99% v AUR, vytvořit balík je jednoduchý atd.
K čemu pro tebe Ubuntu, kde se snažíš popírat jejich filozofii a řešit neaktuálnost aplikací dalšími repositáři?
Zdar Max

[ʚĭɞ 🍉]

lol, ne

Respektive, Arch jsem chvíli používal někdy před 12 lety a naprosto nepřichází v úvahu, že bych se k němu vracel.

Hlavní praktický rozdíl, pokud se nic zásadně nezměnilo, spočívá v úrovni automatizace, totiž jestli se balíček prostě jenom někam rozbalí, nebo i obstarává konfiguraci a spouštění služeb. Tzn. Arch znamená práci navíc, kterou hodlat nedělám.

Taky jsem četl nářky, jak změny např. glibc (zrovna teď 2.36) vypekly hlavně uživatele agresivně rolling distribucí jako právě Arch. Díky, nechci.

Co jsem během posledního roku zkoušel, to byla Fedora, protože mi její cyklus vydání a čerstvost aktualizací vyhovuje víc, jenže se ukázala být nestabilní.

Směřuje to k tomu, že tyhle distribuce budou časem immutable s flatpaky/snapy/… pro aplikace, což by mi asi úplně nevadilo, ale než se vyřeší problémy se sandboxingem, to spíš nahodím Nix nebo Guix.

[VoDo]

Urcite te nechci tlacit do Arch, ale to co delas s ubuntu fakt s archem nemusis. Ja jen proste jednou tydne udelam aktualizaci pres prikaz yay a aktualizuje se mi jak oficialni balicky tak AUR veci. Jen je treba teda po instalaci ustit ty sluzby ktery clovek chce mit pusteny, ale to se dlea jednou. Mam Arch dva roky na serveru a zadnej problem, ted druhym rokem na laptopu. Jen te varuju pred ruznejma arch odnozema, to nedelej nebo budes tam kde s ubuntu :)

[k3dAR]

to je uhel pohledu ja treba pouzivam Xubuntu LTS, ale spoustu veci davam z PPA, "cele" Xfce, GIMP, Inkscape, Byobu, mc, LibreOffice, Remmina, Kodi, ... pak jadro z UbuntuMainline(ne-repositar balicku s aktualnima mainline jadrama od Canonicalu), neco si udelam balicek ze zdrojaku... ale zaroven mi vyhovuje ze to cemu PPA nepridam, tak mi drzi verzi do dalsiho LTS... na nekterejch stroji naopak nechavam vse "stock", nebo jen zlomek z PPA...

[Ruža Becelin]

Zajímavé.

Já jsem Ubuntu (resp. Kubuntu, protože Gnome nesnesu) zkoušel na hlavní mašině pár let zpátky, ale vrátil jsem se zase k Fedoře, která mi víc vyhovuje z hlediska stability a historicky jsem v ní víc doma.

Release cyklus je sice trochu ehm, ale vzhledem k tomu, že mi liché verze přijdou míň odladěné, tak se snažím dělat upgrade sudá-sudá a liché přeskakovat (pokud se tam zrovna nevyskytne aplikace, která opravuje dost zásadní bugy), což už se dá akceptovat.

Je ale fakt, že mi odjakživa víc sedí RPM distra, než DEB.

[ʚĭɞ 🍉]

Je ale fakt, že mi odjakživa víc sedí RPM distra, než DEB.

Tohle jsem nikdy nepochopil. Rozumím, že je to naprosto odlišné pro balíčkáře, ale jako uživatel – prostě se pár příkazů jmenuje trochu jinak (nebo ani ne, třeba PCLOS měl a asi pořád má APT nad RPM).

[Ruža Becelin]

Takhle - z pohledu balickare mi RPM sedi jeste vic, neco jsem se nabalil a DPKG mi fakt nevonel... To ani nemluvim o Gentoo ebuildech, ty jsou fakt super...

O apt/yum/dnf ani nejde, na to mam wrapper tak 15 let, ale spis jde o usporadani repositaru, chovani balicku, atd.

Urcite je to ovlivnene tim, ze jsem majoritu profesni kariery stravil v Red Hat-like vecech, ale proste mi to sedi vic.

V urcitou dobu mi treba dost vyhovovalo Gentoo, ale nechtel jsem se s tim drbat a automatizace byla v plenkach, tak jsem se vratil k Red Hatu.

Dalo by se to shrnout: Red Hat Linux 5.x-6.x -> SUSE Linux 7.x -> Red Hat Linux 7.x -> Slackware 7.x-8.x -> Debian 3.x -> Gentoo -> RHEL 5.x-7.x -> Fedora 12-28 -> Ubuntu 16.04-20.04 -> Fedora 30-36 + sem tam neco jineho, co bylo zrovna potreba

[podlesh]

Já jsem balíčky několikrát ve své kariéře vyráběl a o rpm nemohu říct nic pozitivního. O rpmbuild pak nemám jediný komentář vhodný do slušné společnosti. I když, občas to jsou zábavné historky k pivu.

Pravda, asi je to ovlivněno tím že v některých případech jsme balili balíčky na RedHat serveru, což vím že byla zásadní chyba.

[Ruža Becelin]

To je mozne, ja jsem mel vyclenene build servery, ktere fungovaly OK, takze si stezovat nemuzu

Ale jak rikam, je to dost individualni...

[podlesh]

To je mozne, ja jsem mel vyclenene build servery, ktere fungovaly OK, takze si stezovat nemuzu

Ale jak rikam, je to dost individualni...

Redhaty?

Bývalo zvykem (pravda, je to přes 10 let), že RedHat měl v sobě extra scripty, které se samy automaticky naprdelili do rpmbuild` aby ten výsledek "vylepšily". Například jeden takový script našel všechny .py soubory a zkompiloval je do .pyc. Další script pak zkontroloval zda noarch balíček náhodou neobsahuje binárky a pokud takovou binárku, například nějaký .pyc soubor, našel, tak celý build zastavil s FATAL ERROR. Takže jsme museli python aplikace balit jako i386 nebo x64...

Jiný script zase našel všechny .jar soubory, rozbalil je v tempu a pak zase zabalil aby byly soubory v abecedním pořadí. Samozřejmě že místo mktemp bylo použito hardcoded jméno adresáře, takže paralelní buildy si navzájem přepisovaly a mazaly soubory.

No prostě srandy pytel.

[Ruža Becelin]

Jo RHEL a CentOS.

S tim .pyc je to zajimave, ale my jsme v te dobe s Pythonem nedelali, takze jsme tyhle problemy nemeli.

Jar jsme balili, ale nas build server delal chroot pro kazdy build, takze se paralelni buildy navzajem nevidely.

Co si vzpominam, tak kolem rpmbuild jsme meli nejaky hook skripty, co uklizely pred a po, takze jsme se s nejakymi problemy nesetkavali.

[Ruža Becelin]

Jeste bych dodal, ze v dnesni dobe Ansible/Docker/whatever uz je celkem jedno, jaky clovek pouziva podvozek. Treba Fedora Silverblue je hodne zajimava vec...

[JiK]

ja jsem nejak prestal mit rad ubuntu, kdyz zacali s tema flatpack a snap balickama, nevim, proc je potreba dalsi zbytecny format. prinasi to (krome chaosu) neco navic proti predchozim balickovacim systemum?

kdyz zacali s tema flatpack...

Ubuntu Flatpaky nikdy nepoužívalo. Naopak je Canonical již od začátku docela úspěšně bojkotuje a tlačí namísto nich svůj Snap.

[Mayhem]

Aha, takze kolibac je ubuntak, tim se to vysvetlilo. Budme na nej hodni.

[❗Červivý Hřib krade❗]

nejvěčí zahada je že kolibáč má blog ale neni to jakoby vubec vidět u jeho profilu napsaný :O :O :D ;D

[xxxs]

to by mohlo znamenat, ze komunizmus je blizko. co sudruhovia nevidia, to nemozu zobrat.

[Ruža Becelin]

> svetr udělá za zimou tečku. muj svetr hřeje tebe tvuj mě. dva svetry jsou jistota. noste 4tý posilující svetr

[❗Červivý Hřib krade❗]

to je +- parafráze z mackova blogísku :O :D

už to nemužu najít ale todlecto je taky dobrý hele :D :D

Plynu v ČR bude na podzim a v zimě dostatek. Jen při bližší analýze došlo k upřesnění, že nebude v potrubí, ale v ulicích, a nebude zemní, ale slzný.

[Ruža Becelin]

Taky dobry

[xxxs]

ked ti v dalsom roku pride fakturka za zemny, tak si aj zaslzis.