Názory k článku
Balíčkovací systém umožňující koexistenci verzí
-
Je to popsáno tak, že máš třeba dvě apliace. Dejmetomu Foo a Moo. Moo chceš stabilní, protože testovací verze padá. Ale chceš testovací verzi Foo, protože umí něco víc a nepadá. Jenže obě chtějí knihovnu SuperLib. Bohužel testovací verze Foo potřebuje tetovací verzi SuperLibu a Moo s testovací evrzí nedokáže soužít. Takhle můžeš mít dvě verze SuperLibu a funguje obojí. -
ivan (neregistrovaný)Tak uz tu mame:
1. verzovani symbolu primo ve .ELF souborech. Tzn, klidne je mozne aby existovala knihovna libjpeg.so, ktera by byla kompatibilni s libjpeg6a i libjpeg6b a kazdy program by v ni nasel ty "spravne" symboly podle toho se kterou verzi byl kompilovan.
2. Pak tu mame verzovani jmen souboru knihoven podle libtoolu
http://developer.apple.com/documentation/developertools/glibtool/libtool_6.html
3. pak tu mame ruzne -compat baliky v ruznych ditribucich.
A nakonec tu mame novy balikovaci sw, ktery dela skoro to same.
Proc lidi porad dokola vymysleji kolo, misto toho aby si precetli nejaky standart, aby mohli vyuzit vsech jeho vlastnosti? To jako byli lidi pred 5ti lety uplny idioti a nenapadlo je, ze neco takovyho bude potreba? -
Mintaka (neregistrovaný)Kdyby to všechno bylo tak snadné jak popisuješ, pak by asi nikoho ani nenapadlo vymíšlet něco dalšího.
1. Nejsou tu jen binárky
2. Ne nadarmo začíná textem "The most difficult issue..."
3. Nejen proto, že různé distribuce instalují aplikace na různá místa, a že je občas mění k obrazu svému.
4. 5. 6. --> Nová řešení se objevovala odjakživa, objevují se i teď a objevovat se budou. Chvála Bohu.
BTW: "Ideální" řešení zatím v nedohlednu. -
Tak to o tom verzování symbolů jsem nevěděl. Je to zajímavé.
Každopádně domnívám se, že to samo o sobě asi nestačí. Protože, pokud bychom měli nějakou rozsáhlou knihovnu, není nutné aby si nesla nutně kompatabilitu přes n verzí. Nepříklad GTK+ 1, 2, 3, nebo KDE 1, 2, 3, 4.
Ale jinak souhlasím, že už těch řešení toho samého je privela.
ČLÁNKY DO MAILU