Příspěvky

1

Hardware / Re:Kontrola a refresh SSD disku?

« kdy: 17. 11. 2023, 22:00:17 »

V té první by měla data vydržet - 1 rok při 30 st. C, u druhé 3 měsíce při 40 st. C.

viz. Retention Use (power off) na stránce 26
https://www.jedec.org/sites/default/files/Alvin_Cox%20%5BCompatibility%20Mode%5D_0.pdf
uložená data.

Jen aby to nevyznělo tak tragicky, zapomněl jsem zmínit, že na další stránce je celá tabulka (podle modelu na zrychlené testování, podobně jako u jiných médií to samozřejmě nikdo nemůže zkoušet v reálném čase .
Při nižší teplotě, data drží samozřejmě déle.

2

Hardware / Re:Kontrola a refresh SSD disku?

« kdy: 17. 11. 2023, 21:36:01 »

fstrim --all

To vám spustí trim na všech připojených filesystémech, které podporují trimování. Včetně třeba systémového disku, což většinou nechcete atp.

Tohle rozhodně samo o sobě neřeší nějaké "osvěžení" paměťových buňek z hlediska udržení informace, jen to pošle odpovídající HW příkaz (TRIM, UNMAP, deallocate) pro bloky filesystému, které jsou neobsazené. Můžete to dělat buď automaticky na pozadí, když filesystém maže data (pokud má mount volbu discard), nebo právě jednou za čas manuálně přes fstrim.

Je fakt, že u některých zoufalých SSD, které třeba vykazují velká zpomalení v některých částech své celkové kapacity, tohle může pomoct (než ho třeba definitivně vyhodíte), ale neřeší to přímo zmíněnou životnost dat.
Nicméně když už to je v tomhle stavu, že tohle budete chtít vyzkoušet, tak je lepší přesunout všechna data, odmountovat a zrušit filesystémy na disku a pustit spíš příkaz blkdiscard.
Ten narozdíl od fstrim nepracuje s jednotlivými volnými bloky filesystému, ale pošle do zařízení najednou celý rozsah sektorů, které má uvolnit. Bez parametrů je to komplet celé zařízení, ale dá se specifikovat i třeba nějaký rozsah (offset, délka).
Jinak je blkdiscard samozřejmě dobrý také třeba, když řešíte nějaký thin-provisioned disk, kde rušíte staré filesystémy, a budete vytvářet nové.

3

Hardware / Re:Kontrola a refresh SSD disku?

« kdy: 17. 11. 2023, 21:16:09 »

SSD vyžadují napájení... pokud jsou napájená, řeší si obnovu i verifikaci sám kontroler. Netřeba dělat nic.

Přesně tak.

Díky, to je mimořádně zajímavá informace. Mohu poprosit o zdroj? Ne že bych tomu nevěřil, ale rád bych si přečetl víc.

Co vím, jsou v podstatě dvě kategorie SSD, které ve svých dokumentech definuje JEDEC - Client (consumer) a Enterprise.
V té první by měla data vydržet - 1 rok při 30 st. C, u druhé 3 měsíce při 40 st. C.

viz. Retention Use (power off) na stránce 26
https://www.jedec.org/sites/default/files/Alvin_Cox%20%5BCompatibility%20Mode%5D_0.pdf

Ty celé dokumenty s odpovídajícími standardy JESD.... jsou bohužel neveřejné (jen pro členy JEDECu).
Ale je k dispozici výše zmíněná prezentace, kde je docela hutný výtah. Včetně metodik pro určování výdrže, specifikace testovacích workloadů atp.

Já si myslím že je to hloupost. Sám jsem kopíroval zálohu několika Gb z uloženky ssd něco přes tři roky nepoužívaného a vše be problémů. Více zkušeností tady: https://www.abclinuxu.cz/poradna/linux/show/492557

To bohužel neznamená, že se na to můžete spolehnout. Ty výše zmíněné standardy neříkají, že to ztratí data za danou dobu. Nicméně pokud konkrétní SSD nemá ve své specifikaci uveden nějaký delší čas, kdy vám bude výrobce garantovat, že to udrží data bez napájení, tak bych všechno nad tyhle základní údaje v JEDEC normách (podle kterých to testují a udávají specifikace) bral jako bonus.
Osobně mi také SSD víceméně drží data, ať už třeba vyřazená v nějakých SATA->USB krabičkách, v podstatě na odkládání, nebo třeba jako systémové disky ve stanicích, které jsou ve skladu předinstalované jako náhradní. Ale rozhodně bych to nebral jako médium pro nějaké off-line uchovávání důležitých dat. Minimálně bych to občas celé zapnul a třeba verifikoval data podle nějakých kontrolních součtů, co mám uložené jinde.
Tím nejen ověříte integritu, ale určitě zabere ten controller uvnitř a stoprocentně přistoupíte ke každé buňce, kde máte uložená data.

4

Server / Re:HP microserver GEN8 pomalý zapis na disky

« kdy: 02. 11. 2023, 00:54:23 »

Ještě pár hodnot na porovnání.
Dnes se mi dostal shodou okolností do ruky také HP Microserver Gen 8, základní model se slabším CPU G1610T.

Měl jsem po ruce dva volné HDD. Starý 2TB Hitachi vytažený z vyřazeného pole a novější 6TB Seagate IronWolf Pro.
Vyzkoušel jsem dd zápis s tím samým příkazem pro srovnání.
Pak jsem totéž zreplikoval v benchmarku fio (balíček ve většině distribucí), který umožňuje nastavit zmíněný queue depth (QD), abyste viděl rozdíl.

Device Model:     HDS723020ALA640 RSD HUA

dd
user@lunar:~$ sudo dd if=/dev/urandom of=/dev/sda bs=1M count=1k status=progress oflag=direct
1068498944 bytes (1.1 GB, 1019 MiB) copied, 16 s, 66.7 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 16.0867 s, 66.7 MB/s

fio QD 1
Run status group 0 (all jobs):
  WRITE: bw=64.2MiB/s (67.3MB/s), 64.2MiB/s-64.2MiB/s (67.3MB/s-67.3MB/s), io=7700MiB (8074MB), run=120006-120006msec

Run status group 1 (all jobs):
   READ: bw=138MiB/s (145MB/s), 138MiB/s-138MiB/s (145MB/s-145MB/s), io=16.2GiB (17.4GB), run=120003-120003msec

fio QD 8
Run status group 0 (all jobs):
  WRITE: bw=137MiB/s (144MB/s), 137MiB/s-137MiB/s (144MB/s-144MB/s), io=16.0GiB (17.2GB), run=120050-120050msec

Run status group 1 (all jobs):
   READ: bw=138MiB/s (145MB/s), 138MiB/s-138MiB/s (145MB/s-145MB/s), io=16.2GiB (17.4GB), run=120061-120061msec

Model Family:     Seagate IronWolf Pro
Device Model:     ST6000NE0023-2EX110

dd
user@lunar:~$ sudo dd if=/dev/urandom of=/dev/sdc bs=1M count=1k status=progress oflag=direct
1072693248 bytes (1.1 GB, 1023 MiB) copied, 14 s, 76.6 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 14.0178 s, 76.6 MB/s

fio QD 1
Run status group 2 (all jobs):
  WRITE: bw=77.7MiB/s (81.5MB/s), 77.7MiB/s-77.7MiB/s (81.5MB/s-81.5MB/s), io=9329MiB (9782MB), run=120003-120003msec

Run status group 3 (all jobs):
   READ: bw=222MiB/s (232MB/s), 222MiB/s-222MiB/s (232MB/s-232MB/s), io=26.0GiB (27.9GB), run=120001-120001mse

fio QD 8
Run status group 2 (all jobs):
  WRITE: bw=222MiB/s (233MB/s), 222MiB/s-222MiB/s (233MB/s-233MB/s), io=26.0GiB (27.9GB), run=120032-120032msec

Run status group 3 (all jobs):
   READ: bw=222MiB/s (233MB/s), 222MiB/s-222MiB/s (233MB/s-233MB/s), io=26.1GiB (28.0GB), run=120034-120034msec


Je tam pěkně poznat, že se po zvýšení QD propustnost při zápisu víceméně srovná se čtením.
Jinak finální výkon a optimalizace celého systému pro daný workload má spoustu aspektů, co to můžou ovlivnit.
Tohle je ideální kombinace velkého bloku a příhodného QD, a hází to víceméně maximální propustnost pro rotační disky na začátku plotny.

5

Server / Re:HP microserver GEN8 pomalý zapis na disky

« kdy: 02. 11. 2023, 00:14:18 »

Ještě jsem mkrnul do biosi a radič byl v modu Legacy tak se omluvám za mystifikaci, přepnul jsem ho do AHCI (někde jsem ale četl, že by to na výkon nemělo mít vliv). V gparted se teď dostanu na 60MB/s viz příloha. Pořád je to ale polovina. sde je SSD.

Tak to bylo tím. Legacy režim emuluje režim UltraATA (staré paralelní IDE), které má reálná maxima okolo těch původních hodnot.
Naměřených 60-70 MB/s je takhle napřímo přes dd do točivého SATA disku a bez další optimalizace scheduleru zařízení v Linuxu normální. Oproti těm 20 MB/s předtím, to byl exces.

Důvod je ten, že za této situace (s dd) se do zařízení zapisuje typicky jeden blok současně a je tam aktivní jeden I/O request. Jinými slovy - queue depth je 1  (z max. 32 u SATA zařízení) a zdaleka se nevyužije možnost efektivnějšího přenosu a optimalizace zápisu do disku.
Čtení ve výchozím nastavení scheduleru je trochu jiné, tam se ještě projeví přednačítání bloků (read-ahead), takže to se i takhle s dd a bez optimalizace přiblíží maximální propustnosti z disku.

Nebál bych se toho, v reálném provozu a s případnou další optimalizací bude ta rychlost sekvenčního zápisu daleko vyšší. Podle mě se klidně dostanete na ten dvojnásobek. To dd bylo jen rychlá cesta, jak zjistit, že tam nemáte jiný problém.

6

Server / Re:HP microserver GEN8 pomalý zapis na disky

« kdy: 01. 11. 2023, 14:47:22 »

A co s tím pak v Linuxu udělá? Ten B120i RAID řadič měl nějaké poslední ovladače od HP do starého RHEL (6 když ten server uvedli, pár prvních releasu pro 7 možná). Když tam není tenhle ovladač, nevidíte to ani jako blokové zařízení (na rozdíl třeba od obecných fakeraidů Intel RST, RSTe)

7

Server / Re:HP microserver GEN8 pomalý zapis na disky

« kdy: 01. 11. 2023, 14:39:27 »

Každopádně, tím testem rovnou do těch blokových zařízení jste vyloučil jakýkoliv filesystém. Takže nemá moc smysl řešit optimalizace ZFS, BTRFS, nějakého MD RADIu atp., dokud se nerozsekne proč jsou tak pomalé ty samotné disky.

8

Server / Re:HP microserver GEN8 pomalý zapis na disky

« kdy: 01. 11. 2023, 14:36:43 »

To je fakt divný, ty disky by měly bez FS dávat daleko víc. Další divnost je, že je to na všech portech a discích +/- stejná hodnota.

Ten řadič HP B120i je takový divný hybrid, první dva porty mají 6Gbit SATA, druhé dva pak 3Gbit. Ale pořád i 3Gbit je to hodně nad tím, aby to limitovalo točivé disky.
Už si bohužel přesně nepamatuju, co jsem konkrétně předtím řešil za konfiguraci G8 a které tam bylo CPU (myslím, že ten slabší Celeron, ne Xeon), disky byly tuším HGST DC.

Nicméně podobný HP Gen8 Microserver se mi někdy tenhle týden dostane do ruky, můžu to zkusit změřit, dám vám vědět.

Ještě mě napadlo, kolik dává pro zajímavost to SSD, co máte na systém? Počítám, že je to připojené na stejném SATA řadiči místo interní CD mechaniky.. takže kdyby tam bylo úzké hrdlo, mělo by se to taky projevit.

9

Server / Re:HP microserver GEN8 pomalý zapis na disky

« kdy: 01. 11. 2023, 12:31:10 »

Kód: [Vybrat]

dd if=/dev/zero of=/mnt/kde_mam_zfs/tempfile bs=1M count=1024 conv=fdatasync status=progress

zkus raid2z na 4 discich

Nevím v jakém to má tazatel teď stavu - zkoušel tam různé souborové systémy, ale zatím bych neházel žádná doporučení na různé konfigurace ZFS, přehazování vdevů, když zatím vůbec neví, čím to je.
Pokud na tom nejsou zatím žádná data, tak bych začal přímo testem blokových zařízení, abych vyloučil problém s hardwarem a teprve pak bych šel do vyšších vrstev.
Takže dd napřímo do zařízení toho jednotlivých disků.
Např. na Linuxu bych tam poslal něco jako

Kód: [Vybrat]

dd if=/dev/urandom of=/dev/sdX bs=1M count=1024 oflag=direct status=progress

Takovýhle gen 8 server jsem před pár lety nastavoval jako NAS s FreeBSD a ZFS, byl tam byly 8TB disky v ekvivalentu RAID10 (dva mirrorované vdevy), 8GB RAM. V podstatě bez jakékoliv výkonové optimalizace (výchozí blocksize pro dataset - 128k). Pro takovýhle sekvenční zápis při kopírování velkých souborů jsem byl někde okolo 80-100MB/s přes síť a SMB2.

10

Software / Re:Widevine s VMP na Linuxu - v čem je problém?

« kdy: 31. 10. 2023, 13:02:40 »

Nefunguje vám to pod Linuxem ani v Chromu nebo Firefoxu?

Standardně by jak Firefox, tak Chrome (z oficiálních balíčků od Google) měl podporovat Widevine L1.
U Chromu je to out-of-box součástí jejich distribuce.
U Firefoxu se to pak cca do minuty po prvním spuštění v profilu stáhne do domovského adresáře. Následně se to dá ověřit přítomnost content decryption modulu (CDM) v about:plugins.

Základní ověření funkčnosti webu jde udělat např. na:
https://shaka-player-demo.appspot.com/demo/ (prostřední video "Sintel" bude zašedlé a nepůjde spustit, když nebude funkční Widevine)
případně otevřete:
https://shaka-player-demo.appspot.com/support.html
Vrátí vám to JSON strukturu, kde by mělo být

Kód: [Vybrat]

"com.widevine.alpha": {
      "persistentState": false
    },

Pokud to bude null, nefunguje to.

Jinak nemám osobně přístup k aktuální dokumentaci a API od Widevine (ta je dostupná jen těm firmám, co to mají zaplacené).
Ale co si vybavuji z nějakých předchozích debat a postů.
Pokud poskytovatel obsahu (tzn. třeba Skylink, HBO, Spotify..) chce maximální úroveň té DRM ochrany (Widevine L1 + VMP), tak se ověřuje aplikace z které se volá CDM modul. Cca do r. 2020 to bylo ve výchozím stavu v API vypnuté, a muselo se to explicitně zapnout, tzn. ve výchozím stavu to chodilo i z neověřených aplikací. Třeba když někdo vyextrahoval tu dynamickou knihovnu a pak ji zavolal z Kodi, Chromia, nějaké Electron aplikace atd.
Od r. 2020 je to obráceně, ověřování je ve výchozím stavu zapnuto a pokud chce poskytovatel obsahu povolit přístup z neověřených aplikací musí to udělat přes API.
Takže i tohle hraje roli a může to způsobovat to, že to na konkrétní konfiguraci od některých poskytovatelů chodí, a od některých ne.
Netuším, jak to má Skylink. Ale to je ten důvod, proč jsem zmiňoval ozkoušení z oficiálního balíčku (rpm, deb) pro Chrome. U Firefoxu je to trochu složitější, už jsem viděl, že sestavení Firefoxu z balíčku některých distribucí nefunguje, ale třebe ofiko Flatpak od Mozilly https://flathub.org/apps/org.mozilla.firefox chodí.

Ještě zmíním, že jsem celou dobu měl na mysli x86_64, pro ARM je to ještě komplikovanější i když existují oficiální Linux Widevine knihovny pro armhf a od loňska i arm64 (RPi 3,4,5).

11

Software / Re:iVysílání není podporováno v OS Linux

« kdy: 15. 08. 2023, 11:55:45 »

Tady už to jede klasicky po jiné koleji a stala se z toho filozofická diskuze o OS , zkusím se vrátit k tématu.

Co vím a zkoušel jsem, tak iVysílaní v aktuální verzi nepoužívá nic úplně nestandardního - H.264/AAC kodeky, MSE (aka Media Source API), EME (Encrypted Media Extensions) pro DRM přes Widevine CDM od Google.
Tzn. standardní W3C technologie + nejrozšířenější DRM.
Obecně pokud prohlížeč tyhle technologie podporuje, tak ten ČT HTML5 přehrávač chodí, a není omezen na konkrétní platformu nebo architekturu.
Je to podobné jako spousty jiných současných video/audio platforem, kde majitelé práv na obsah vyžadují DRM. (Od Netflixu, přes Disney až po Spotify)

S oficiálními balíčky a instalátory Google Chrome je v tomhle ohledu jednodušší, protože mají rovnou v sobě jak CDM modul, tak potřebné dekodéry/wrappery na systémové knihovny už dlouhou dobu. Standardní prohlížeče na mobilní platformy, Windows, macOS také.
Na Linuxu u Firefoxu, podobně Chromia nebo u nějakých ještě obskurnějších odvozenin to bohužel závisí na dalších faktorech. S jakými nastaveními byl prohlížeč sestaven do balíčku, příp. jestli je to třeba Snap přímo od Mozilly, jaká konkrétní verze prohlížeče (viděl jsem i balíčky s neoficiálními patchy, kdy se to pak chovalo jinak), jaké je výchozí nastavení pro nový profil v prohlížeči, jestli jsou v systému přítomné potřebné všechny dekódovací knihovny, nebo ve výchozím stavu preventivně odstraněny třeba kvůli právům na jejich celosvětové použití atp.
Praktický problém u autorů web aplikací pak spočívá v tom, že se některé tyhle aspekty dopředu nedají spolehlivě detekovat, takže přes různé doporučené způsoby detekce vlastností prohlížeče se stejně můžete dostat do situace, kdy vám třeba nějaký test skript i s heuristikou vrátí, že to je všechno v cajku. Příp. featury jsou odfajfkovány v testovacích stránkách pro konkrétním prohlížeč, ale až když opravdu spustíte přehrávání reálného steramu tak to selže. Proto ty přehrávače také často vrací úplně obecné chybové hlášky.

Teď k tomu Ubuntu s Firefoxem. Není to můj denní chleba, ale občas něco řeším s LTS verzemi distribuce, nebo někomu pomáhám.

Tam jsou v podstatě dvě varianty instalace Firefoxu - buď výchozí ze snapu, nebo deb balíček. V novějších verzích se ten druhý, klasický způsob musí vynutit. Neuším, jak se to chová při upgradech systému.
Jestli máte verzi ze snapu (doporučuji), tak tam ty kodeky rovnou jsou jeho součástí.
Pokud máte balíčkovou verzi, tak musíte doinstalovat aptem ještě ffmpeg a ideálně i libavcodec-extra + jejich závislosti.

Pro Fedoru, RHEL a odvozeniny je pak potřeba přidat odpovídající rpmfusion repozitář a také nainstalovat ffmpeg.

Nakonec jak tu už předtím zaznělo, je třeba v nastavení Firefoxu dohledat zaškrtávátko "Přehrávat obsah chráněný pomocí DRM", resp. anglický ekvivalent. Po jeho zapnutí se pak na pozadí stáhne Widevine plugin do profilu uživatele. Chvíli to trvá než se to stáhne a nainstaluje, nakonec by to mělo být vidět v about:plugins

Pokud byste měl chybu s DRM, tak to přehrávač iVyílání korektně detekuje a řekne tuhle konkrétní chybu.

12

Vývoj / Re:Oprava zdvojených lomítek

« kdy: 11. 11. 2017, 15:20:49 »

Tohle jde snadno i přímo v Bashi bez volání jiného interpretru na regexy.

Pro náhradu: "//" -> "/" je to takhle:

echo ${myVar//\/\//\/}

tzn. před každým lomítkem ve vyhledávaném řetězeci nebo náhradě musí být ještě zpětné - jak bylo řečeno je to escape znak.
Navíc je zdvojené i první lomítko za názvem proměnné, protože to pak nahrazuje všechny výskyty vyhledávaného řetězce.. bez zdvojení by to nahradilo jen první výskyt. Je to podobné jako přepínač /g v sedu.

13

Server / Re:Kam systém na RAID 1

« kdy: 12. 04. 2015, 14:36:30 »

md RAID-1 se dá udělat i přes celé disky (musí s tím samozřejmě počítat GRUB a software pro obluhu vytváření initrd, nevím jak je to u Debianu, ale RHEL/Centos6 to zvládá). Což ušetří opruz s klonováním bootloaderu při případné výměně disku.

Nicméně pokud jde o domácí NASy, tak to většinou řeším tak, že je tam malý USB flash disk na kterém je umístěn /boot a zbytek systému a uživatelská data pak na pevném disku v RAIDu. Odpadne tím problém s bootováním ze sw RAIDu i případné potíže, kdy je v systému první vadný disk a NAS následně nenaběhne, protože BIOS některých deskách nedokáže bootovat z druhého (nebo se třeba "kousne" na nějakých nekonečných I/O timeoutech na prvním vadném disku).

ZFS mi na malé domácí NASy přijde trochu overkill, pokud systém nemá dostatečný výkon a paměť (např. různé slabší Atomy), pak je i docela dost pomalý (v porovnání s md) a například resilvering na těchto konfiguracích trvá i několik dní, zvlášť pokud jsou tam připojeny např. 3TB disky. Samozřejmě jeho pokročilé vlastnosti mohou být pro někoho lákavé, ale u mě většinou převáží krom zmíněného i to, že není standardní součástí Linuxu.
FreeNAS je docela fajn, ale samozřejmě FreeBSD základ má i praktické nevýhody - například nemožnost použít inotify pro akutalizace databází různých DLNA aplikací.

Michal

14

Distribuce / Re:Debian - balíčky s různými volbami pro sestavení

« kdy: 10. 03. 2015, 16:31:57 »

Řeší se to pomocí Gentoo...

Jj, to je také zajímavá distribuce..

Ahoj,

  nevim, jestli je nejaky standardizovany postup. Osobne to resim skriptem, ktery pro kazdou verzi baliku nakopiruje do build stromu novou verzi debian subadresare (tj. s jinym predpripravenym rules a control souborem). Pak tim skriptem vyrabim jednu verzi za druhou. Je to staticke, a dost blbovzdorne. Mozna existuje neco lepsiho, rad si to poslechnu, ale prijde mi, ze je nutne menit primarne jen rules a control (a v tom muze byt pomerne dost zmen - napr. ty Depends ...). Tim skriptem vyrabim rovnou i .rpm a .tgz verze (ale to uz je jina).

V tomhle duchu jsem o to taky přemýšlel.. Nějak si automatizovat víc verzí řídících souborů.
U rpmbuildu se to řeší přes parametry při kompilaci --with/--without s odpovídajícími podmínkami (http://www.rpm.org/wiki/PackagerDocs/ConditionalBuilds) takže na všechno stačí jeden .spec soubor. Hledal jsem tu něco podobného, ale i varianta s několika adresáři "debian" bude nejspíš schůdná.

V Debianu se to dělá tak, že pro různé volby sestavení jsou různé balíčky, přičemž balíčky, které mají nějaké volby navíc, jsou označeny „Provides: balíček-bez-těch-voleb“. Společná data jsou pak v dalším balíčku. Typický příklad by byly balíčky Vimu: vim, vim-nox, vim-gtk, vim-gnome, vim-athena; společná data v vim-runtime (platformově nezávislá data) a vim-common (platformově závislá data).

Aha, to je také dobrý tip.. Sestavit to rovnou víckrát se všemi volbami a doladit "Provides" tak, aby se to případně nehádalo a chovalo korektně při aktualizacích. Mrknu se na ten vim a rozdělování balíčku obecně (resp. vícenásobné deklaraci Package: v debian/control).

Děkuju za vaše příspěvky,

Michal

15

Distribuce / Debian - balíčky s různými volbami pro sestavení

« kdy: 10. 03. 2015, 11:50:33 »

Ahoj,

po mnoha letech s distribucemi založenými na RPM a BSD porty přecházím na některých počítačích na Debian. Chtěl bych položit jeden související dotaz.
Řešili jste někdy výrobu/úpravu balíčku, který by měl měl různé volby jeho sestavení? Typicky jde o rozsáhlejší programy, které mají hromady parametrů pro ./configure, co ovlivňují kompilaci a linkování s externími knihovnami.
Samozřejmě jde parametry explicitně vypsat (upravit) v debian/rules, který se zdá být normální Makefile, a upravit debian/control soubor, aby reflektoval aktuální závislosti (položky Build-Depends a Depends).
Spíš jsem měl na mysli univerzálnější řešení, co by umožnilo mít balíček, který půjde pomocí nějakých parametrů volitelně sestavit např. s podporou GUI, knihovnami s non-GPL licencemi atp. Ideálně bez toho, aby muselo být balíčků několik (with-gui, non-free..).

Našel jsem používanou proměnnou DEB_BUILD_OPTIONS, do rules by se pak daly přidat podmínky, co upraví prarametry pro ./configure "CONFIG += ..". To se zdá být jednou z variant, ale jak potom vyřešit, aby v control souboru byly ty správné závislosti, které se podle vyhodnocení podmínek budou měnit.

Jak tohleto řešíte?
Příp. příklad balíčku, kde je to řešeno (a odkud bych se mohl inspirovat správným řešením "Debian Way" .

Tak nějak jsem hledal na Debian Wiki, díval se i do debian-policy manuálu.. ale jsem z toho popravdě zmatený jak jelen.
Obecně vzato chápu jednotlivé věci, ale přijde mi to balíčkování celkově strašně složité.. helper tool, co volá další helper tool, který spustí finální helper tool.. můžu použít asi 5 nástrojů na samotné sestavení.. něco začíná na dh, něco na dpkg a pak nějaký builder.. Snad se to časem poddá

Díky,

Michal