Na crowdsourcingové platformě Crowd Supply byla spuštěna kampaň na podporu open source biometrického monitoru ve tvaru hodinek HealthyPi Move. Cena je 249 dolarů a plánovaný termín dodání listopad letošního roku.
Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Jak se rozdělují soubory do balíčků knihoven, již bylo popsáno v díle věnujícím se programu dh_install
(instalace souborů), takže už víme, že při balení knihovny budeme mít nejméně dva balíčky - libbar0
a libbar-dev
. Kromě nich je ještě dobré vytvořit balíček s ladicími informacemi libbar0-dbg
(k tomu nám pomůže dh_strip
popsaný dříve), a pokud knihovna obsahuje i větší množství dat, můžeme je od ní oddělit do balíčku libbar-common
.
Balíčků nám tedy může vzniknout mnoho a určitě by mezi nimi měly být nějaké
závislosti, abychom vždy dostali funkční balíček. Pro vývojový balíček budeme
potřebovat knihovnu ve stejné verzi, proto musí záviset na libbar0 (= ${binary:Version})
. Balíček s daty je sice samostatně celkem k ničemu, ale i přes to si ho někdo může chtít nainstalovat bez knihovny (například může chtít použít data v něm obsažená v jiném programu), a proto použijeme jen doporučení (Suggests
) na libbar0
. Vlastní knihovna oproti tomu data určitě potřebovat bude, proto zde závislost musíme zavést. Podle charakteru dat musíme vybrat, jak striktně budeme vyžadovat stejnou verzi. Obvykle se ovšem používá závislost na stejné nebo novější verzi, tedy libbar-common (>= ${source:Version})
. Poslední je balíček s ladicími symboly, a ten samozřejmě nemá smysl s jinou verzí knihovny, než ze které byl vytvořen - libbar0 (= ${binary:Version})
.
Ostatní problémy, se kterými se můžete setkat při vytváření balíčků knihovny, se již nijak neliší od jiných balíčků, ale na správné závislosti je třeba si dávat pozor.
Moduly pro Python by v systému měly být k dispozici pokud možno pro všechny
nainstalované verze Pythonu a měly by být zkompilované do byte-kódu. To je asi
hlavní požadavek, který dal vzniknout dvěma programům pro přípravu pythonních
balíčků - python-central
a python-support
. Oba v současné době nabízejí srovnatelné možnosti a jediný důvod, proč budu dále popisovat python-central
, je ten, že jej používám; python-support
by posloužil stejně dobře. Mezi autory těchto programů sice panuje menší nevraživost, ale to nevadí tomu, aby vám kterýkoliv z nich dobře posloužil.
Oba dva přesunou moduly do svého adresáře a při instalaci je zkompilují do
byte-kódu a nějakým způsobem je předhodí Pythonu. Toto samozřejmě funguje jen
pro moduly, které jsou napsané jen v Pythonu a neobsahují žádnou kompilovanou
část. Tyto kompilované je potřeba při vytváření balíčku zkompilovat pro
všechny podporované verze Pythonu. Program pyversions
nám prozradí, které verze jsou v současné době podporované, a v debian/rules
se pak podle toho musíme zařídit a použít všechny verze Pythonu, takže kompilace bude vypadat například následovně:
PYVERSIONS=$(shell pyversions -r) ... build-stamp: dh_testdir # Build normal modules set -e; \ for python in $(PYVERSIONS) ; do \ $$python setup.py build ; \ done
Dále ve finální fázi vytváření balíčku musíme spustit pomocný skript
dh\_pycentral
, který nám dopočítá některé substituční proměnné pro
debian/control
a vygeneruje skriptíky pro správné nainstalování modulů v systému.
V souboru debian/control
musíme kromě nových závislostí (python-all-dev
a python-central
) uvést několik nových polí:
Source: python-bar ... XS-Python-Version: all Package: python-bar ... Provides: ${python:Provides} XB-Python-Version: ${python:Versions} Depends: ${shlibs:Depends}, ${python:Depends}
Pole XS-Python-Version
u zdrojového balíčku určuje, pro které verze Pythonu balíček je možné balíček zkompilovat. Obvykle je to možné pro všechny a můžeme tedy použít hodnotu all
. U binárního balíčku se pak do XB-Python-Version
doplní, pro které verze Pythonu byl balíček zkompilován, a v závislostech používáme další nově vygenerované proměnné.
To by pro základní moduly pro Python mělo stačit, podrobnější popis Problematiky naleznete na wiki.
Poslední případ balíčku, který si dnes popíšeme, jsou démoni. Tedy spíš cokoliv, co se spouští při startu systému a má spouštěcí skript. Nejdůležitější část je vytvořit tento spouštěcí skript; vlastní instalaci a zařazení do startovací sekvence již zařídí dh_installinit
. Spouštěcí skript umístíme do zdrojového balíčku jako debian/binární-balíček.init
.
Pokud démon má nějaké parametry z příkazové řádky, je vhodné dát uživateli
možnost je změnit v konfiguračním souboru umístěném do /etc/default/
. Tento adresář obsahuje části skriptů, které jsou obvykle ve spouštěcím skriptu použity právě pro specifikaci parametrů spouštěných služeb. Pokud ve zdrojovém balíčku budeme mít soubor debian/binární-balíček.default
, nainstaluje ho dh_installinit
jako /etc/default/binární-balíček
a pak ho můžeme ze spouštěcího skriptu použít.
Jak by tedy spouštěcí skript měl vypadat? Protože Debian dodržuje zásady LSB, měl by obsahovat standardní hlavičku s informace o službě, kterou poskytuje. Pokud jsme vytvářeli balíček programem dh_make
, ten nám vytvořil ukázkový spouštěcí skript jako debian/init.d.ex
a tento nám může dobře posloužit jako
základ pro další práci.
Pokud program používá databázi, máme také možnost tyto databázi vytvářet v
rámci skriptíků spouštěných při instalaci a vytvořit konfigurační soubor s
přístupovými parametry do databáze. Veškerou tuto činnost má na starosti
balíček dbconfig-common
. Ten v současné době podporuje MySQL, PostgreSQL a SQLite a umožní základní nastavení databáze, vytvoření uživatelů a na případné dotazy se ptá uživatele pomocí debconfu.
Kompletní návod k použití zde vypisovat nebudu, ale v zásadě je použití
jednoduché a ukážeme si ho na příkladu pro MySQL (pro jiné databáze stačí
změnit mysql v následujících příkladech za odpovídající text). Přidáme skript pro vytváření potřebných tabulek do balíčku jako /usr/share/dbconfig-common/data/jméno_balíčku/install/mysql
a ve skriptíkách přidat volání dbconfig-common
. Do jméno_balíčku.config
přijde jen konfigurace:
. /usr/share/debconf/confmodule if [ -f /usr/share/dbconfig-common/dpkg/config.mysql ]; then . /usr/share/dbconfig-common/dpkg/config.mysql dbc_go jméno_balíčku $@ fi
V jméno_balíčku.postinst
pak můžeme i třeba vygenerovat konfigurační soubor v PHP (dbconfig-common
nabízí i jiné formáty):
. /usr/share/dbconfig-common/dpkg/postinst.mysql dbc_generate_include_owner=www-data dbc_generate_include=php:/etc/jméno_balíčku/config-db.php dbc_go jméno_balíčku $@
Pak už jen stačí zařídit, aby se vygenerovaný soubor nějak použil v aplikaci a vše by mělo automaticky fungovat. Podotýkám, že toto je nejjednodušší použití, ale je možné dělat i mnohem složitější operace, včetně aktualizace struktury databáze při aktualizaci na novou verzi.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Opačně to není nutné, protože data je třeba možná použít i v něčem jiném (at už to je jakkoliv pravděpodobné).Tady bych byl opatrný, pokud maintainer myslí, že libbar0-data je možno použít i jinak než v libbar0, měl by zároveň garantovat nějakou funkčnost balíku libbar0-data. Což ho omezuje v takových akcích jako smazání půlky souborů v nějaké revizi.
A ani to není dobré, protože by vzniknul kruh závislostí a to může způsobit problémy při instalaci.Dost by mě zajímalo, čím a jaké problémy to způsobuje. Vím, že o tom čas od času jistý B.A. vyvolá na -devel flame, ale ty jeho zdůvodnění jsou tak trochu divný. Že cokoli rozbije dist-upgrade nic neznamená, dist-upgrade je rozbitý sám o sobě. Že to zvětšuje složitost vyhodnocování a splňování závislostí prostě není pravda. Problémy s pořadím spouštění instalačních skriptů sice můžou být, ale ne pokud jeden z těch balíků ty skripty nemá atd.
Jinak je potřeba mít závislosti tak, aby samostatná migrace nemohla nastat.No jo, ale jak to udělat?
Dost by mě zajímalo, čím a jaké problémy to způsobuje. Vím, že o tom čas od času jistý B.A. vyvolá na -devel flame, ale ty jeho zdůvodnění jsou tak trochu divný. Že cokoli rozbije dist-upgrade nic neznamená, dist-upgrade je rozbitý sám o sobě. Že to zvětšuje složitost vyhodnocování a splňování závislostí prostě není pravda. Problémy s pořadím spouštění instalačních skriptů sice můžou být, ale ne pokud jeden z těch balíků ty skripty nemá atd.Spíš bych ten problém formuloval opačně: jaký je dobrý důvod k vytvoření kruhové závislosti? V mnoha případech sice problém nezpůsobí, ale to není důvod jich mít v distribuci stovky a komplikovat tak jakýkoliv upgrade.
Při migraci se kontroluje jestli se nerozbijí závislosti jiných balíčků, takže pokud potřebuju nějakou verzi dat, stačí to dát do závislostí, např.:Jinak je potřeba mít závislosti tak, aby samostatná migrace nemohla nastat.No jo, ale jak to udělat?
Package: program Depends: data (>= 1.0), data (<< 1.1)