biicode, balíčkovací systém pro C a C++ (diskuse)

[Ivorne]

Nikdy jsem nebyl moc příznivce Pipu nebo Rubygems. Proč mít v systému několik balíčkovacích systémů? Tuhle jsem dělal něco v Ruby a potřeboval jsem tam nějakou knihovnu a musel jsem jednak nainstalovat systémový balíček pomocí Portage a pak Ruby binding pomocí Rubygemu. Ne, že by mě to zas tak iritovalo, ale nechápu, proč si to uživatelé tak chválí. Jako teoreticky je tam jakási multiplatformovost. Ale reálně mi přijde, že je multiplatformnost dost podobná jako u systémových balíčkovacích systémů - když ten balíček vývojář neudělá dobře, nebo to neotestuje na různých distribucích, tak je kolikrát snazší instalovat to bez použití jakéhokoliv balíčkovacího systému.

Jako neříkám že tyhle balíčkovací systémy jsou úplně k ničemu, jen nemůžu přijít na to, k čemu vlastně jsou. A hlavně mám pocit, že spousta lidí, kteří to hrozně chválí to taky neví.

[gauri]

pokud chci neco vyzkouset a nazasvinit si system zavislostma co to ma, popr. testovat neco proti jiny verzi knihovny nez mam v systemu, tak pip s virtualenvem jsou dost sikovny…

[pavlix]

Mimochodem jsem se bavil s vývojáři Enlightenment a rovněž chystají svůj vlastní balíčkovací systém ve stylu těch s Pythonu a Ruby a považují to za natolik skvělou věc, že někteří z nich nevidí smysl v tom mít aplikace balené pro jednotlivé distribuce. Jinak třeba Pythoní distutils jsou udělané docela dobře, ačkoli nezvládají některé základní věci jako rozlišování bin a sbin. Běžné programy jsou pak zabalené tak, že je lze do distribuce jednoduše přebalit v podstatě bez práce. A tak by to podle mě mělo být vždy navrženo.

[Sid]

Potom by mozno nebolo od veci aby existoval nejaky multiplatform projekt ako kniznica ktory by dokazal naviazat sa na tieto jednotlive balickovacie systemy a poskytoval by nejake high-level api pre balickovaci system na urovni celej distribucie.

[pavlix]

To nedává smysl. High level API pro balíčkovací systémy pokud vím i existuje, jenže high level znamená, že na to budeš moci navázat aplikaci pro výběr a instalování balíčků. Samotné balíčky jsou z principu low level, pilíř, na kterém se všechno staví.

Vytvořit obecný vstupní balíčkovací formát by nebyl až takový problém, jenže někteří distributoři trvají na svých příšerných formátech a jakémukoli zlepšení se budou zuby nehty bránit. Ať se nebavíme trochu na objektivní úrovni, je zjevné, že většina světa (Debian a spol. je výjimkou) má potřebu minimalizovat množství a složitost vstupních dat pro balíčkovací systém mimo upstreamový tarball. Takže deb je první adept na zahození. RPM má své quirky, ale už zhruba odpovídá něčemu, co by se dalo používat, stejnětak ebuild na gentoo nebo pkgbuild v archu.

Pak je ještě potřeba, aby se chytili za hlavu správci některých upstreamových projektů. Opravdu není důvod, abych půlku buildsystému musel konfigurovat/programovat v rámci těch vstupních informací. Balík by měl jít zkompilovat tak, že opíšu závislosti z README a řeknu o který buildsystém se jedná. Pak už jenom upravuju volby a závislosti podle potřeby distribuce.

[Sid]

mozno som to napisal trocha nepresne ale v principe mi islo o toto: ako uzivatel by som preferoval keby som nemusel vzdy ked chcem nieco nainstalovat skumat 5 minut syntax toho konkretneho balickovacieho systemu (alebo mat 5x rozne GUI pre toto). Chcel by som nieco na sposob napr dnf (hocico ine) install nazov package. Je mi jasne ze uplne low level veci by sa s tym nedali urobit ale povacsine pri beznych veciach to ani uzivatel nemusi riesit. To ze na pozadi sa zavola napr ruby gem by ma az tak nemalo zaujimat. Takze ani ma nezaujima nejaky obecny format (aj ked by to bolo skvele).

[pavlix]

mozno som to napisal trocha nepresne ale v principe mi islo o toto: ako uzivatel by som preferoval keby som nemusel vzdy ked chcem nieco nainstalovat skumat 5 minut syntax toho konkretneho balickovacieho systemu (alebo mat 5x rozne GUI pre toto).

Jako uživatel přece nic takového neděláš a používáš distribuční balíčky, které instaluješ pomocí jednoho GUI. Právě proto jsem nechápal, co že to vlastně požaduješ.

Chcel by som nieco na sposob napr dnf (hocico ine) install nazov package.

Tak to ale přesně funguje.

To ze na pozadi sa zavola napr ruby gem by ma az tak nemalo zaujimat.

O tom rozhodují maintaineři těch konkrétních Ruby balíčků a jako uživateli ti to může být jedno.

[Sid]

a ako je to presne urobene? Funguje to tak, ze napr rpm balicek ma v sebe nejake scripty ktore na pozadi volaju napr gem? Mne by prislo logickejsie keby cela ta cinnost bola presunuta priamo do nejakeho pluginu nad systemovym balickovacim programov a napr v rpm by bol cisto iba obaleny balicek pre ten konkretny balickovaci system.

[pavlix]

a ako je to presne urobene? Funguje to tak, ze napr rpm balicek ma v sebe nejake scripty ktore na pozadi volaju napr gem?

Nejsem ruby package maintainer. Jestliže daný nástroj maintainerům něco přináší, tak ho používají i v tom RPM. Například v Pythonu je to velice jednoduché, protože stačí spustit setup.py. Nejsou potřeba žádné extra skripty nebo pluginy. Ale například Gentoo má rozšíření pro Python, které umí automaticky buildovat pro jednu nebo více verzí Pythonu dle přání administrátora systému.

Mne by prislo logickejsie keby cela ta cinnost bola presunuta priamo do nejakeho pluginu

On to vůbec nemusí být plugin. Jediné, co člověk potřebuje, je balík nakonfigurovat dle pravidel distribude, zkompilovat, pokud je to potřeba a instalovat do speciální cesty. Tam už si to v případě RPM převezme ten builder a vyrobí z toho RPM balík. Není v tom žádná velká věda.

Navíc ten plugin nepatří do koncového systému, ale do buildovacího systému. Setká se s ním tedy vývojář nebo provozovatel té buildovací služby. Bavíme se přece o distribučních balících a finálním produktem má být vždy balík ve stejném formátu pro danou distribuci. Samozřejmě lze instalovat i balíky z cizích zdrojů, ale to už jaksi není součást té které distribuce, že.

Akorát v tom Gentoo je vlastně buildovací služba součástí lokálního systému, takže tam o hodně věcech rozhoduje administrátor. A tam je to třeba pro Python řešeno přesně tím pluginem (přesněji) do toho buildovacího systému, ale jeho úkolem není jenom zavolat setup.py, ale zavolat ho třeba i několikrát s různým prostředím a poskytnout tak uživateli build třeba i pro více verzí Pythonu.

Hlavní je si nepředstavovat nějaké složité procesy, vždycky je to jen nějaká obdoba ./configure && make && make install DESTDIR=/path/to/temporary/destination, pár metadat, a zbytek už je jenom napravování věcí, co vývojáři nějak pokazili nebo zbytečně zkomplikovali.

[Sid]

dik za info

[Radek Miček]

jen nemůžu přijít na to, k čemu vlastně jsou

Balíčky jsou nezávislé na distribuci. Vlastní balíčkovací systém může odstranit některá omezení distribučního balíčkovače (např. nainstalovat různé verze jednoho balíčku naráz).

[Ivan]

Vezmete si treba rozdil mezi RHEL(rpm) a Perl(CPAN). RHEL obsahuje jen velice malo knihoven a casto jsou dost zabugovane. Takze pokud doopravdy potrebujete Perl - napriklad proto, ze v nem mate napsane monitorovaci scripty - tak pouzijete jadro OS z distribuce a zbytek si sam prelozite ze zdrojaku.

PS: i Java ma svuj maven a C# zase NuGet.

[Ruža Becelin]

Samoty RHEL snad nikdo nepouziva, ne?

[mirec]

Je to dobré na jednu vec. Keď moja napr. webová aplikácia je testovaná a beží dobre pod určitými verziami knižníc tak pocou pip je možné do samostatného adresára nainštalovať závislosti pomocou jednoduchého pip install -r requirements.txt (v rovnakých verziách ako má programátor). Pri deployi na server napr. cez git hook je možné automaticky spustiť pip install --upgrade -r requirements.txt a automaticky sa pre daný projekt natiahnu knižnice ktoré používal programátor a zvyšok systému si beží nezávisle na ňom (nedotkne sa to softvéru ktorý potrebuje napr. staršiu verziu knižníc). Pre gem platí to isté.

[Michal Karas]

Pre gem platí to isté.

Samotné rubygems to nezvládnou, ale snad všichni rubysti na to dnes používají bundler.

[Michal Karas]

A jen teda ještě doplním, že oblíbené jsou také nástroje RVM a rbenv, které umožňují instalaci více verzí/implementací Ruby a přepínaní mezi nimi.

[pavlix]

Nakonec ty webovky stejně budete distribuovat v dockeru nebo něčem podobném :D.

[Michal Karas]

Immutable infrastructure

[pavlix]

Nemám zájem o odkazy bez zjevného kontextu a vysvětlujícího komentáře.

[Michal Karas]

Odpusť.

[tomvec]

Keď moja napr. webová aplikácia je testovaná a beží dobre pod určitými verziami knižníc tak pocou pip je možné do samostatného adresára nainštalovať závislosti pomocou jednoduchého pip install -r requirements.txt (v rovnakých verziách ako má programátor).

Takže na Windows opovrhovaná "vlastnost", kdy si aplikace tahají s sebou vlastní verze knihoven se nenápadně (volitelně) prodrala do linuxu?

[pavlix]

Ani ne tak nenápadně a ani ne tak do Linuxu.

[tomvec]

Tak tedy se vztyčenou hlavou a multiplatformně.

[Ivan]

Tohle je deje i jinde. Treba na OSX ale hlavne v Jave. Pro JEE a maven je to de-facto standard. Programator sam urci se kterou verzi knihovny se to ma kompilovat, maven to vsechno postahuje, zkompiluje, udela z toho balik a ten se nahraje na aplikacni server. Pokud funguji kontejnery jak maji tak nikomu nevadi ze pouzivate najednou vic verzi jedne knihovny.

ok wokna maji svuj dll-hell (pozdeji nahrazeny tzv. "manifest hell"), ale v podstate jde to kdo rozhodne s jakou verzi knihovny se bude program kompilovat/linkovat. Programator anebo spravce baliku? Odpoved ale neni jednoznacna a hodne zavisi na typu projektu.

[R]

Cize na serveri je potom plno deravych neaktualizovanych sraciek a neda sa to nijako vyriesit. Krasa...

[mirec]

Ako by ste to chceli riešiť?

[Michal Kubeček]

To nám tu ještě chybělo… :-(

[kralyk z abclinuxu]

Tohle má dnes kdejaký jazyk, Golang to dokonce integruje přímo v kompilátoru, Rust má Cargo, JavaScript má npm atd. atd. Pokud se to dá rozumně ovládat a může to spolupracovat s distribučním balíčkovacím systémem, nemám nic proti... (Což ale, mam pocit, u toho Go zrovna moc neplatí...)