Ubuntu 16.04-ben bevezetésre kerül a Snap alapú csomagtelepítés

Ubuntu Linux

Olli Rie bejelentette, hogy az Ubuntu 16.04-ben bevezetésre kerül a Snap alapú csomagtelepítés.

A hírről a webupd8 is tudósított.

A deb alapú csomag telepítés is megmarad, remélhetőleg hosszú ideig!

Ebben a témában már volt egy eszmecsere itt a hup-on.

  • 7422 megtekintés

( manfreed (nem ellenőrzött) | 2016. 04. 15., p – 09:25 )

Ez olyan nagy baj?

Szerintem is jó. Arra gondolok, hogy például majd LibreOffice 7.0-át vagy a Python 3.7.1-et talán nem a PPA-kból kell telepíteni az akkorra már "elavult" Ubuntu 16.04-hez, hanem lesznek hivatalos snap-csomagok.
Vajon az Ubuntu upgrade-je hogyan fog zajlani, ha sok snap-csomag van rajta?
tray majd biztosan teszteli:-)

________________________________________
https://sites.google.com/site/eutlantis/

( enpassant v | 2016. 04. 15., p – 12:09 )

Ahogy nézegetem ez nem ugyanaz, mint ami egy éve tervezve volt.
Ott még szó volt framework-ökről, amiktől függhet, ebben az "új"-ban nem látok ilyet.
Azt írják, hogy minden függőséget tartalmaz egy csomag.

Ha jól értem, akkor, ha akarok Java-s programokat snap-be csomagolni, akkor a JRE-t bele kell raknom minden egyes csomagba.
Jól értem?

>>Ha jól értem, akkor, ha akarok Java-s programokat snap-be csomagolni, akkor a JRE-t bele kell raknom minden egyes csomagba.
Jól értem?

Szerintem nem, ha megfelel az a JRE verzió, amit a platform szolgáltat. Én ennek látnám értelmét, de nem vagyok szakértő:-)
________________________________________
https://sites.google.com/site/eutlantis/

Pont egy egy szakértő válaszára lennék kíváncsi, mert az Ubuntu honlapján található információk elég szűkösek és ellentmondásosak.

Tavaly még a snappy-ről volt szó (használata), ahol lehetnek framework-ök, mint a JDK, Qt, ... és app-ok, amik ezekre a framework-ökre épülnek.

Ez az új snap csomag más lehet, mert kicsit más a neve (snap vs snappy) és más programmal kell kezelni (snapcraft vs snappy). Ennél még kevesebb az infó, mint a snappy-nél, amit találtam ott mindenhol az volt, hogy szeparáltan működik az OS-től és minden függősége bele van csomagolva.

Egy videót találtam a Java-s snap csomag készítéséről, de ez is inkább csak reklám, mint információ.
Ez a videó is inkább azt sugallja, hogy belekerül a Java futtató környezet a snap csomagba.

Még az is növeli a zavart, hogy néhol snap-nek hívják, néhol snappy-nek.

Valaki hozzáértő mondja már el, hogy a snap a snappy utódja-e, vagy csak egy szűkebb implementációja és ezek majd összeérnek, vagy egy és ugyanaz, de akkor hová tűntek a framework-ök, vagy hogy is van ez?

Hogy fog ez működni security szemszögből? Pl. szállítják a szoftvert egy ismert sérülékenységgel rendelkező OpenSSL-lel... Erre eddig értelmes választ nem adott senki :-(
Mennyi tárhelyet, memóriát fog felhasználni pl. a 20-30 példányban jelenlevő Qt teljes függőséggel?

Fura ez nekem. De majd megint Ubuntu-troll leszek :-).

Ezek a dolgok nem újdonságok.

Windows alatt is oda van csomagolva minden program mellé az összes dll amit használ...

OSX alatt is ott van az alkalmazásba csomagolva minden ami kell ahhoz, hogy fusson...

Feltételezem amúgy, hogy a teljes QT nem lesz ott függőségként, meg olyan modulok (mint pl az openssl) amit elvárhatunk, hogy ott legyen az alaprendszer nevű csomagban. Azt is feltételezem, hogy mondjuk bizonyos szintű függőségrendszer mégis csak lesz. Mondjuk egy külön KDE csomag fog kelleni egy Krusadernek. De legalább nem 30-40 különböző libről beszélünk, mint függőségről, hanem 1 extra nagy csomagról.

Egyébként amit én szeretnék tudni, az az, hogy a snappyval mennyivel lesz másabb az alkalmazások portolhatósága. Milyen könnyen tehetem meg azt pl, hogy egy alkalmazást magammal viszek egy pendrive-on configokkal együtt.

Nyilván én is csak feltételezni tudok, mint bárki más. Mondjuk úgy, hogy bizakodó vagyok, és nem egy használhatatlan valamit kapunk :)

A DLL hell amúgy tényleg elgondolkodtató, viszont OSX alatt nem hallom hogy gond lenne ebből. Talán az ő példájukat érdemes másolni.

Azok az odacsomagolások azért teljesen mások. Azért is volt a DLL hell, mert ugyanabból a DLL-ből eltérő verziókat kellett volna telepíteni és ezek összeakadtak.

A snap csomagoknál egyfajta sandbox-osan vannak csomagolva a függőségek, egymáséit nem (sőt szerintem az alap libeket sem) látják.

Windows alatt is oda van csomagolva minden program mellé az összes dll amit használ...
Ebbe ne menjünk bele. Faxa új HP nyomtató telepítése: első gépre csont nélkül felkúszott, másodiknál "végzetes hiba történt" és "az eszköz nem használható a gépen". Nem két percet küzdöttem a feladattal. Eljutottam oda, hogy csak a nyomtató drivert kérem, nem kell hozzá semmi más csili-vili program: a végzetes hiba nem múlt el. Összehasonlítva a két gépet az egyiken fent van a MS .NetFramework 2.0 - ezt telepítve a renitens gépre a nyomtató hirtelen telepíthetővé vált. Ezen a ponton viszont:
- nagyon nincs mellé rakva, ami kell
- a hibát detektálja a rendszer, meg is nyilvánul róla - de azt a pár szavas extra infót, hogy "tedd már fel ezt is", nem bírja kiköhögni

( uid_16313 | 2016. 04. 15., p – 16:22 )

Nem úgy volt eddig, hogy a köztes verziókban jelentek meg új Feature-ök, és nem az LTS-ekben?

--
robyboy

( golgota | 2016. 04. 15., p – 16:50 )

Hat elolvasva a nsap csomagok keszitesenek mikentjet, ugy nez ki hogy nem lesz semmi hozzacsomagolva. A .meta majd leirja, hogy mi kell a te X csomagodhoz dependenciaban, mint ahogy ez most is van a deb-ben. A lib-ek, bin-ek ugyanoda kerulnek. Inkabb egy yaml-esitett rpmbuild-re hasonlit, csak regeteg pluginnal. :D

Az elonyet en abban latom, hogy tenyleg gyorsabban lehet kulonbozo verzioju csomagokat kesziteni (azaz mondjuk egy deb altal nem tamogatott kde5 snap-pal siman felrakhato a 14.04-re).

Viszont nem nagyon tiszta, hogy mennyire lehet szetcseszni igy a rendszert. Van fent mondjuk egy adott lib, amit egy snap csomag nem szeret es leszedi, de a db-bol felrakott progiknak meg az kellene. Ezt a kevert csomagkezelest eleg veszelyesnek tartom. Mondjuk egy "mount" felrakva egy deb-bol felulirodik egy snap csomaggal, akkor mi lesz? Vagy akkor nem engedi telepiteni, ha fent van deb-ben snap-bol? Van ilyen plugin a snap-ban ami ellenrozi, hogy deb csomagbol esetleg mar fent van e?

Jo ertettem, meg elolvastam ezt https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ es klonozott snapcraft-ban megneztem a pluginokat.

Ertem, hogy ha csak snap van, akkor minden szep es jo, vagy ha csak deb van.

A kerdes tovabbra is az, hogy hogyan kepzeltek, hogy ezek egyutt vannak egy rendszeren. Vagy en ertettem flere valamit es az egyutt azt jelenti, hogy lesz olyan ubuntu amin apt lesz es lesz amin snap? (flavor vagy spin vagy minek nevezik)

Csak tippelni tudok.

Fent van az alaprendszer, apt-gettel azt módosítod, a snappy-s dolgok meg efölé települnek. Gondolom nem lesznek olyan csomagok a snappyben mint amiket deb csomagoknál megszoktunk, pl libek, meg ilyesmik, hanem csak önálló alkalmazások (mint mondjuk ... telefonon)

"ugy nez ki hogy nem lesz semmi hozzacsomagolva. "

Kíváncsi vagyok, hogy hol találtad ezt infót, mert én ennek pont az ellenkezőjét találtam mindenhol. Esetleg egy linket mellékelhetnél.

"Van fent mondjuk egy adott lib, amit egy snap csomag nem szeret es leszedi"

Ilyet meg biztosan nem csinál, épp az a lényege, hogy szeparált kis dobozkákat telepít, amiben benne van minden függősége. Az csak a kérdés, hogy vannak-e framework csomagok (pl. JDK, Qt, ...), ahogy kezdetben tervezték, amitől függhetnek az app csomagocskák, vagy hogy ténylegesen minden benne van minden app csomagban.

A fejlesztőtől függ, hogy mit csomagol be:

"Snappy packages can be statically linked and include their own copies of any file they need. Developers can use the exact library versions they want, and they get to control when those libraries are changed, or use the core system libraries from Ubuntu if they prefer."
Forrás:https://developer.ubuntu.com/en/snappy/
________________________________________
https://sites.google.com/site/eutlantis/

nem, nekem nem ezzel van gondom.
inkább security, meg frissítés szempontból.

mert jó, nyilván nyűgös most, hogyha valaki random-lib 2.0 használatával adja ki az alkalmazást, de más app meg random-lib 3.0-t akar, akkor mi is legyen (semver legyen, az!).
de ezzel meg lesz egy rakat app, ami a régi, bugos, security-hibás libet hozza magával, mert a fejlesztőnek egyszerűbb statikusan odarakni, mint 10-15 minor verzióval tesztelni...

de ne legyen igazam (ilyenkor hol van BZoltan?)
--
blogom

Még ugyan nem használok snappy-s Ubuntut, ezért csak találgatok, de nem látom sötétnek a jövőt.

Ma mi a helyzet, ha telepítünk egy a nem hivatalos Ubuntu repóból származó .deb csomagot, amiben statikusan vannak libek? Az Ubuntu Update Manager ezt nem ellenőrzi biztonsági szempontból ma sem. Miénk a választás, hogy használunk-e ilyen csomagokat, és ha igen, akkor időnként ellenőrizzük-e őket vagy sem, és ha "lejárt a szavatossága", akkor kidobjuk-e vagy sem.

A snappy csomagokkal szerintem ugyanez lesz a helyzet.
Másrészt a hivatalos ubuntus snappy csomagok többség vélhetően a core rendszer libjeit fogja használni, mert így a Canonicalnak egyszerűbb a karbantartás. Nyilván csak ha indokolt, akkor olvasztanak be libeket a snappy-be. Úgy gondolom, hogy nem túl nagy feladat a Canonical számára úgy továbbfejleszteni az Update Managert, hogy az a snappy-kbe is belenézzen.

________________________________________
https://sites.google.com/site/eutlantis/