Új, egyszerűsített csomagformátumot, alkalmazástelepítőt kaphat az Ubuntu

Ubuntu

Egy, az ubuntu-devel listára küldött üzenetben Colin Watson arról írt, hogy az Ubuntu egy új, egyszerűsített csomag(olási)formátumot és alkalmazástelepítőt kaphat annak érdekében, hogy a fejlesztők egyszerűbben készíthessenek csomagokat rá. Nem arról van szó, hogy a meglevő csomagkezelőt dobnák. Továbbra is maradnának a dpkg / apt vonalon, az új csomagkezelő a meglevő kiegészítője lenne. Főként - legalábbis kezdetben - az Ubuntu phone/tablet vonalat céloznák meg vele.

Részletek a bejelentésben.

+1 volt már szerencsém pár hibrid rendszerhez, és soha semmi jó nem sült ki belőle. Persze ha sikerül valahogy nekik egybegyúrni, és a felhasználó semmit nem vesz észre belőle (grafikus és konzolos megoldás esetén egyformán), akkor eselteg. Másik, hogy ne készítsen már boldog boldogtalan csomagot :) szerintem a mostani flow sem bonyolult, legalábbis egy fejlesztőnek, akinek meg az, az inkább ne f0ss4 tele a repókat, meg floodolja a mainstreamereket hibás csomagokkal.
-
Reflection - a bajkeverő csodagyerek

Mondjuk elég ezt a két guide-t összehasonlítani:

http://www.debian.org/doc/manuals/maint-guide/

http://fedoraproject.org/wiki/How_to_create_an_RPM_package

Aki próbált már deb csomagokat előállítani esetleg patchelni,backportolni az nagyjából tudja, hogy a sajtreszelővel rejszolás minősített esete. Többféle pathcelési metódus quilt,dpatch, kézi heggesztés, debhelper verzió hell, compat level agyrém, debsrc verziózás....

Ettől még én jobban szeretem a deb (apt) alapú disztrókat, de nem a csomagkészítés miatt az biztos.

( saxus | 2013. 05. 08., sze – 21:09 )


 * no dependencies between apps; single implicit dependency on the base
   system by way of a Click-Base-System field
 * installs each app to an entirely separate directory
 * entirely declarative: maintainer scripts are forbidden

Most akkor lassan eljutnak a .msi-hez? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerintem ugyanezt is reagáltam :-) De mivel lassan megtörni látszik a jég, és egyre inkább úgy tűnik, hogy szerintük sem tökéletes a PBI-nek ez a huncutsága, a PC-BSD akár még jó is lehet. (De itt a cikkben valami olyasmi is szerepelt, hogy elsősorban a tablet/mobil vonal miatt szeretnék. Pedig szerintem azokban azért jellemzően kevesebb a háttértár, és rosszabb lehet mobilhálózaton egy sürgős OS-upgrade.)

Szerintem teljesen jó ötlet. Alapvetően nagyon utálom, amikor egy adott alkalmazásnak olyan verziójú lib-re van szüksége,
amiből mondjuk egy régebbi van a rendszerben, ha azt viszont updatelem, akkor meg más halja össze magát. Baromira nem érdekel,
hogy mekkora egy program, az alaprendszeren kívüli függőségeit nyugodtan hozza magával, és működjön stabilan. Nyilván most
desktop-ról beszélek.

Windózul úgy mondják a problémát, hogy dll-hell. Az, hogy egy app, ami a /opt/szutykok/ alá települ a futtatásához igényel egy "export LD_LIBRARY_PATH=/opt/szutyok/lib/" -ot, az addig hagyján, amíg egy-két ilyen van. Amikor azonban a legtöbb vicikvacak is hozza a saját .so-jait, és ugyanabból fent lesz 23 verzió, amiből 20 körüliben vannak randa sérülékenységek - nos, az már nem lesz vicces.
Mondjuk ha statikusra van fordítva a cucc, ez a probléma akkor is előkerülhet, de legalább nem lesz azonos célú .so-ból n+1 darab...

> amiből mondjuk egy régebbi van a rendszerben, ha azt viszont updatelem, akkor meg más halja össze magát
Hát igen. Mivel minden disztrib egy-két évente (félévente) frissíti magát, aki neki áll appot írni, az a legújabb libeket használva fogja releaselni a cuccát -> nem azt nézi, hogy a libjpeg.so-ból hányas verzió _kell_ a saját programjának funkcionalitásához, hanem azt, hogy épp a rendszerén hányas _van_. Ezt összevetve a stabil API hiányával valószínűleg a jövőben megjelenő újabb libekkel is inkompatibilis lesz. És így tovább. Ha nekem kéne desktop appot fejlesztenem, ma (2013-ban) valószínűleg Ubuntuval10.04-gyel és RHEL6-tal tesztelném.

Alapvetően nem a függőségkezeléssel volt gond IMHO, hanem azzal, ahogy a platform, illetve az appok fejlesztői viselkedtek.

Akkor kerlek old meg a kovetkezo problemat ezzel a rendszerrel:
* van 300 app a telodon, ami hasznalja az x lib 1.1-es verziojat (ugye mindegyik hozza magaval a sajat konyvtaraban)
* felfedeznek a fejlesztok egy bug-ot az x lib 1.1-es verziojaban, ami miatt tetszoleges kod futtatasat teszi lehetove a device-on -> kiadjak az 1.2-es verziot

Vedd ra mind a 300 fejleszto ceget, hogy updateljek a kiadott appokat (sajat idejukbol/penzukbol ugye). Sok sikert.

Ertem.
Akkor mar csak a kovetkezoket kell megoldani:
* definialni milyen library-k tartoznak az "alapkonyvtarba"
* valahogy megoldani, hogy az OS eszlelje, hogy az egyik libnek (ami ugye nincs az "alapkonyvtarban" hanem az appal egyutt erkezik) kiadtak egy uj verziojat es "blokkolni" az appot
* irni egy nagyon kedves uzenetet a felhasznalonak, aminek kb igy kellene hangoznia, hogy: "Kedves Holgyem/Uram, azert nem tudja most hasznalni az Y applikaciot mert az hasznalja az x libet, ami tartalmaz egy sulyos security hole-t. Kerem legyen turelemmel es varjon, hogy az Y app fejlesztoi csapata beleintegralja az X lib uj verziojat az app-ba es feltoltse az app store-unkba. Kerem addig ne legyen ideges mert ez a procedura az on erdeket szolgalja"

Nem toltok tobb idot a meggyozeseddel (igy is tul sokat toltottem).

Neha jo dolog a kulon velemeny :)

Gondolj bele, hogy mi van androidnál? Ott java-ban fejlesztesz, és simán használsz külsős könyvtárakat is, amikben ugyanúgy lehet hiba. Namost, innentől kezdve ha 50 program ugyanarra a könyvtárra épít, amiben ugyanaz a hiba van, akkor bizony pontosan ugyanez a helyzet áll elő. Az első védővonal egyébként, hogy nem engedünk native programokat futtatni, hanem csak managelt-eket, így az olyan programozási hibákat, mint pl. buffer overflow, jó eséllyel kivédhetjük. Arra pedig, hogy alkalmazásokat távolról letiltsanak, mind az android, mind az ios ökoszisztémájában lehetőség van, és bizony néha élnek is vele, bár elsősorban akkor, amikor garázda (malicious) programokat találnak.

Apró különbség, hogy C-ben íródott programok általában nem statikusan vannak linkelve, és nem úgy indulnak, hogy export LD_LIBRARY_PATH=/itt/van/az/app/lib - ezért _is_ létezik olyan, hogy függőség, hiszen az app függ azoktól a libektől, amihez linkelve vagyon (hint: ldd).

A védővonaladra egy nagy -sok. Ugyanus ezáltal el is búcsúzunk az összes speed igényes alkalmazástól.

Mint ahogyan a Motorola Defy-ra nem találtam egyetlen egy zenei alkalmazást sem, ami ne szenvedett volna fél másodperces lag-től. Mindezt a remek VM miatt. Kb. a C64 jobb volt...

Linux-nál (Windows-t nem tudom) verziózva vannak a megosztott lib-ek és nem kell update-elni, hanem létezhetnek egymás mellett az újabb és régi lib-ek. Amelyik programnak a régi kell az azt használja, amelyiknek az új, az meg azt.
Illetve, ha az ajánlások mentén fejlesztik a lib-eket, akkor az újabb lib-nek működnie kellene a régebbi lib-ek helyett is.

Igen, létezhet egymás mellett akárhány verziója is egy shared libnek, amiktől függnek az egyes alkalmazások, mert úgy van kitalálva az egész. Ha a dependency-t eldobjuk, akkor az appnak a csomagban hoznia kell magával az összes libet, amitől függ, aztán... Vagy feltolja saját maga mellé, és LD_LIBRARY_PATH=/az/app/saját/könyvtára következik, vagy megnézi telepítéskor, hogy a számára szükséges, akarom mondani a csomagban benne lévő libek adott verziói léteznek-e már a rendszerben, és ha még nem, akkor felmásolja a saját libjeit a "közösbe", ahonnan viszont akkor, amikor az alkalmazást törlöm, nem törölheti, hiszen nincs arról infója, hogy utána került-e telepítésre olyan app, ami az ő általa a közösbe bedobott lib(ek)et használja. Oké, erre lehet megoldás egy naagy közös kinek, mire van szüksége a közösből adatbázis, amiből a telepítősw meg tudja nézni, hogy használja.e még valaki hivatalosan az xyz.1.2.3.so -t, aztán ha nem, akkor az utolsó app-pal együtt, ami még használta törölheti.

És ez csak az so-függőségre adott válasz, egy program, aminek kell pl. perl, python, php, vagy csak egy szimpla egyszerű utility, az mit csináljon? Hozza magával, maga mellé csomagolva a teljes cókmókot? Egy java-ban írt app pl. a teljes JRE-t? Vagy menjen fel minden vizsgálódás nélkül, és ha nem megy, akkor a README fájl alapján ki lehet találni, hogy mi kell még a futtatásához?

A függőségek kezelése jó dolog. Az, hogy ezt néhányan sz@rul végzik, az nem függőségek leírásának, kezelésének a hibája, hanem a csomag készítőjéé.

<sarcasm> Cask tudnam miert van az a sok szam minden library utan az /usr/lib -ben .. </sarcasm>

Vajon mit csinal az sok szamos bigyo az elf fileokban ? 


readelf -d /bin/bash

Dynamic section at offset 0xdae08 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libtinfo.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

see also: ldd /bin/bash 



Jee, meg tobb digit..
$ readelf -d /usr/bin/gimp                                                                                                                                                                                                   
                                                                                                                                                                                                                                             
Dynamic section at offset 0x5a7760 contains 56 entries:                                                                                                                                                                                      
  Tag        Type                         Name/Value                                                                                                                                                                                         
 0x0000000000000001 (NEEDED)             Shared library: [libgimpwidgets-2.0.so.0]                                                                                                                                                           
 0x0000000000000001 (NEEDED)             Shared library: [libgtk-x11-2.0.so.0]                                                                                                                                                               
 0x0000000000000001 (NEEDED)             Shared library: [libgdk-x11-2.0.so.0]                                                                                                                                                               
 0x0000000000000001 (NEEDED)             Shared library: [libatk-1.0.so.0]                                                                                                                                                                   
 0x0000000000000001 (NEEDED)             Shared library: [libdbus-glib-1.so.2]                                                                                                                                                               
 0x0000000000000001 (NEEDED)             Shared library: [libdbus-1.so.3]                                                                                                                                                                    
 0x0000000000000001 (NEEDED)             Shared library: [libgimpconfig-2.0.so.0]                                                                                                                                                            
 0x0000000000000001 (NEEDED)             Shared library: [libgimpmath-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgimpthumb-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgimpcolor-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgimpmodule-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgimpbase-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgdk_pixbuf-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpangocairo-1.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpangoft2-1.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libfreetype.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libfontconfig.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libgegl-0.2.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgmodule-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgio-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libbabl-0.1.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgobject-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgthread-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( Aadaam v | 2013. 05. 09., cs – 01:12 )

Ez jó, ezért (is) váltottam OS X-re, stabil platform, amiről a "netről" lehet appokat szedni.

A dependency mizériától és a kedves disztribútor hogy forgatta a gimpet vagy a LAMP-ot típusú gondoktól mindig csak a fejem viszketett. Persze szerveren oké, még egy jól beállított dev workstation-ön is azt szeretem ha néhány stack kőkeményen a rendszer része, de azért néha jól esett nyugodtan telepíteni.

(És nekem is eszembejutott a GoboLinux, amiben ez szintén tetszett)

( Dgzt | 2013. 05. 09., cs – 09:06 )

A következő szint az lesz, hogy dobják a Linux kernelt és kap sajátot. :)
---------------------------
Oszt jónapot!

valószínű és lőn megszületik az új osx csak senki egy kanyit sem fog érte fizetni.
egyébként, ha mindent lecserélnek, akkor szerintem nem lesz olyan nagy hype-ja mint most mert rengeteg minden nem fog rajta menni.
aztán kitudja. hátha a fejlesztők meghülyülnek és újraírják a cuccukat az új platformra megint INGYEN.....(amit már egyszer megtettek).
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

( hrgy84 | 2013. 05. 10., p – 22:14 )

Inkabb valtsanak RPM-re, mindenki jobban jar. Vagy nem.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.