Third-Party Debian bináris csomag (.deb) HOWTO

Segédprogramok

Sziasztok!

Szeretnék egy Third-Party Debian bináris csomagot készíteni és ehhez keresek valamilyen jó leírást, útmutatót ill. eszközt. A problémám az, hogy a jelenleg használt 'debhelper' tool (ahogy én látom) csak a hivatalos Debian disztribúcióba bekerülő csomagok készítését támogatja, márpedig én olyat szeretnék csinálni, ami soha sem fog oda bekerülni.

Amit szeretnék:
1) formailag, szerkezetileg standard debian (.deb) csomag legyen, hogy minden debian alapu linux distribúción működjön
2) third-party csomagot készítsen, tehát az /opt ill. /usr/local -ba pakoljon (egyenlőre nem érdekel az /opt vs. /usr/local hitvita!)
3) támogassa a Filesystem Hierarchy Standard (FHS) és a Freedesktop.org ajánlásait (gondolok itt pl. a localizált man-page, menü és az ikonok megfelelő elhelyezésére)
4) esetleg támogassa a globális (minden felhasználó) ill. a user (csak az adott felhasználó számára való) telepítést
5) jó lenne, ha lenne benne, hozzá valamilyen 'lint' jellegű csomag ellenörző eszköz is
6) legyen kiforrott, megbízható és hosszú távon támogatott

Az egyik fő problémám az, hogy hogy lehet az 'XDG Base Directory' rendszert ügyesen felhasználni az általános telepítéshez. A másik kicsit gyakorlatiasabb, a GUI-s programom beágyazása az asztalba, window manager-be. A Freedesktop.org ad ugyan némi útmutatást, de nem tudom, hogy pl. ez mennyire elterjedt szabvány, mennyire tartják be az egyes debián alapú disztribúciók ablak kezelői és szoftveres (tool) támogatást pedig egyáltalán nem találok hozzá.

Tudom, hogy amit kívánok az igen csak maximalista, így nagyon örülnék legalább egy rendes leírásnak, HOWTO-nak is. Előre is köszönök minden ötletet, ami segítene tovább lépnem.

  • 865 megtekintés

- először is köszi a gyors választ
- igen tudom, hogy ezen dolgok a fejlesztő feladatai, de hát éppen itt van a baj, ezzel szenvedek és keresek jobb megoldást
- jelenleg van egy évek óta működő verzióm (és a kedves felhasználók sem háborognak), de én elégedetlen vagyok vele
- az fpm-nél sokkal bonyolultabb a feladat, még a debhelper-t maximumra járatva sem tudom rendesen megoldani a problémát (persze ez lehet az én hibám!)

( st3v3 v | 2023. 11. 07., k – 15:40 )

Szerkesztve: 2023. 11. 07., k – 18:44

Linus sem véletlenül anyázott a csomagkezelőkre, mint alkalmazás fejlesztő :)

( zeller | 2023. 11. 07., k – 15:44 )

A darabolós gyilkos fog egyenlőre  aprítani - de egyelőre még vár vele...

( x-daemon | 2023. 11. 07., k – 18:35 )

es ha vennel egy deb forras csomagot, kicsomagolnad

dpkg-source --extract <filename>.dsc

es kicserelned a "belsejet"?

aztan

debian/rules binary

neked aztan fura humorod van...

( Celtic v | 2023. 11. 07., k – 18:47 )

Sztem a dpkg-buildpackage doksija elég jól elmondja, mitől lesz debian csomag egy deiban csomag. 

De már vagy 15 éve használtam, szóval elég régiek az emlékeim. Azt tudom, egy shell scriptből csináltam deb csomagot, dependency egy darab bináris volt, szóval ment rendesen, dpkg-val telepíthető volt.

http://www.micros~1
Rekurzió: lásd rekurzió.

( aaaaa | 2023. 11. 08., sze – 09:13 )

@x-daemon: Minden már 'kész' csomag az adott program telepítési logikáját tartalmazza, részben éppen a debian/rules-ban. Az én problémám pedig éppen az, hogy hogy is kéne az én speciális esetemben - a különféle elvárásoknak megfelelően - felépíteni a telepítést. Persze tanulni, ötletet szerezni lehet belőle.

@Celtic: A csomag technikai felépítésével tisztában vagyok és azt a debhelper (a Third-Party-ság kivételével) jól támogatja is. Igazából az a 'rendszer szemlélet' hiányzik, ami a különféle standardokat, ajánlásokat összefogná egy egységes rendszerbe és persze az azt támogató tool. Jelenleg én is különféle ad-hoc scriptekkel gányolok és ehelyett keresek valami rendesebb megoldást.

( bzt | 2023. 11. 09., cs – 14:03 )

Szerkesztve: 2023. 11. 09., cs – 14:51

Szeretnék egy Third-Party Debian bináris csomagot készíteni és ehhez keresek valamilyen jó leírást, útmutatót ill. eszközt.

Nem kell hozzá semmilyen program se, alap UNIX-os parancsok több, mint elegendők .deb gyártásához. Csinálsz két tarballt (control.tar.gz és data.tar.gz), egy plain text fájlt (amiben csak annyi van, hogy "2.0"), és ezt a három fájlt berakod egy ar-ba, ennyi.

Ha minta kell, itt találsz, én tipikusan Makefile-ból szoktam összepakoltatni ("make deb" recept).
USBImager Makefile

Arra kell csak figyelni, hogy control.tar.gz-be kerül minden metainfó, és ebben a csomag méretének, verziójának valamint az md5sum-nak stimmelnie kell. Ezt tipikusan így szoktam megoldani:

cat misc/deb_control | sed s/ARCH/$(DEBARCH)/g | sed s/SIZE/`du -s usr|cut -f 1`/g >DEBIAN/control
md5sum `find usr -type f` >DEBIAN/md5sums

A metainfót a deb_control text fájlban tárolom, ebben cserélem le az ARCH és SIZE sztringeket a végleges értékre, a többi marad (az ARCH is csak azért kell, mert multiplatform a projekt, nálad lehet elég direktben beleírni azt, hogy x86_64).
A data.tar.gz pedig tartalmazza a csomagod fájljait, a gyökértől kezdve, teljes elérési úttal.

Mégegyszer: semmilyen 3rd party programot nem használok, csak sima UNIX-os parancsokat (cat, sed, md5sum, tar, illetve ar a binutilsból).

Repó készítésére pedig a tuti megoldás az apt-ftparchive nevű parancs (ne tévesszen meg a név, semmi köze az ftp-hez, ez csak aláírja a csomagokat meg kigenerál minden index fájlt, ami egy debian repóhoz kell).

Az egyik fő problémám az, hogy hogy lehet az 'XDG Base Directory' rendszert ügyesen felhasználni az általános telepítéshez. A másik kicsit gyakorlatiasabb, a GUI-s programom beágyazása az asztalba, window manager-be.

Ehhez csupán helyezz el a data.tar.gz-be egy "usr/share/applications/(programodneve).desktop" fájlt, és kész. Minden általam valaha is kipróbált asztali környezet kezeli (GNOME, KDE, LXDE, XFCE, stb.); ami meg nem tudja (pl openbox) azoknál meg a menumaker automatikusan kigenerálja a megfelelő konfigfájlt a .desktop fájlokból.

USBImager esetén példa desktop fájl. Ez beágyazza a window manager menüjébe. Asztalba ágyazás nem fog menni, mert ahhoz kéne a felhasználó neve, csakhogy a dpkg-t root-ként kell futtatni (szóval max a root asztalára tudsz bármit is kitenni). Esetleg berakhatsz egy postinst nevű shell szkriptet a control.tar.gz-be, ami minden /home/*/Desktop mappába bemásolja a desktop fájlt, de ezt nem javaslom.

Ha a kontext menübe is be akarod tenni, akkor ahhoz csak a .desktop fájlt kell kicsit bővebbre megírni, megadva, hogy milyen mime típusoknál jelenjen meg. Ehhez mintát itt találsz (ez a Minetest Schematic fájlok esetében jeleníti meg, hogy "megnyitás szerkesztésre").

Összefoglalva egy .deb fájl tartalma (fájlnevek és a fájlok sorrendje fontos!):

(csomagneve)_(verzió)-(architectúra|any).deb    (ez egy ar)
|- debian-binary (text fájl, "2.0")
|- control.tar.gz
|   |- control (text fájl, metainfók, kötelező!!!)
|   |- copyright (text fájl, kötelező!!!)
|   |- md5sums (text fájl, a data.tar.gz fájljainak sum-ja, kötelező!!!)
|   \- postinst (shell script, ha van, legyen rajta +x jogosultság, opcionális)
\- data.tar.gz (projekted fáljai, teljes elérési úttal)
    |- usr/bin/(csomagneve) (futtathatód)
    |- usr/share/applications/(csomagneve).desktop (GUI-ba ágyazáshoz)
    |- usr/share/icons/*/(csomagneve).png (ikonok különféle méretben, ezekre hivatkozik a .desktop fájl)
    \- ... (további fájlok)

Magával a .deb csomag technikai összerakásával nincs bajom, mert azt a debhelper infrastruktúrája szépen megcsinálja nekem, ráadásul egy csomó magasabb szintű funkcióval támogatja is a csomag készítését. A baj csak az, hogy mindezt csupán a hivatalos Debian disztribúcióba bekerülő csomagokra vonatkozik, azokra amik nem lesznek annak részei - azaz third-party csomagok lesznek - azokat sehogyan sem támogatja. Sokáig valami olyan kapcsolót, beállítást, trükköt kerestem (és ebben reméltem Tőletek segítséget), amivel a debhelper rendszert rá lehet venni arra, hogy third-party-t generáljon. Sajnos, ahogy most látom nincs ilyen és egyszerűen nem értem, hogy miért nincs!

Én éppen ezt a Te általad is használt 'csináljunk meg mindent mi is, kezdve az alapoktól' módszert akarom elkerülni. Egyszerűen nem működhet úgy egy ilyen igen összetett rendszer, hogy mindenki - szinte ötletszerűen - 'direktbe' beír valamit valahova! Sajnos, - jobb híjján - én is részben éppen ezt a gányolásos módszert csinálom jelenleg.

Az asztali környezetbe való beágyazásnál (ikon, menü, mime-type), a direktbe beírás helyett, pl. a freedesktop.org által javasolt 'xdg-*' tool rendszert használom a debian/postinst-ban. Ez legalább részben valami hivatalos, szabványos megoldás és egy magasabb szintű interface-t biztosít! Kicsit bonyolult, de sajnos jobb megoldást nem találtam.

A third-party csomag minden részének lényegében az /opt-ba (és csak oda) szabad kerülnie az FHS szerint. A man page-ek részére pl. külön is specifikálja az /opt/<package>/share/man-t, hogy az így része legyen a nagy man-page rendszernek (és ez szépen működik is). Az ikonokat, desktop file-okat viszont hova tegyem? Még a most dícsért 'xdg-*' szisztéma is a nagy közösbe teszi őket!

@chx: hivatalosan még a /usr/local-ba sem írhatsz!

Összefoglalva: nem értem, hogy a Debian rendszer (csomag?) megalkotói, hogy is képzelik el egy külső program beintegrálását a Linux rendszerbe! Egyrészt teljesen legyen elkülönítve, másrészt pedig legyen minden szinten szépen integrálva a linux-ba! Ráadásul mindezt úgy, hogy ehhez semmilyen támogatás sincs biztosítva.

A baj csak az, hogy mindezt csupán a hivatalos Debian disztribúcióba bekerülő csomagokra vonatkozik, azokra amik nem lesznek annak részei - azaz third-party csomagok lesznek - azokat sehogyan sem támogatja.

Na akkor most szépen megcsinálja neked, vagy pedig sehogyan sem támogatja? Döntsd már el...

Én éppen ezt a Te általad is használt 'csináljunk meg mindent mi is, kezdve az alapoktól' módszert akarom elkerülni.

Ugyan miért is? Ez tökéletesen működik third-party csomagok esetén is, míg a drágalátós debhelpered meg nem.

Egyszerűen nem működhet úgy egy ilyen igen összetett rendszer, hogy mindenki - szinte ötletszerűen - 'direktbe' beír valamit valahova!

Szó sincs arról, hogy bárki ötletszerűen írna bármit is, a debian csomagok formátuma nagyon is specifikus, és kifejezetten jól sztandardizált! Olvasd csak el a specifikációt. Nagyon is kötött, hogy mit írhatsz bele!

Kicsit bonyolult, de sajnos jobb megoldást nem találtam.

Megint önmagad ellensége vagy. Az a SOKKAL jobb megoldás, hogy eleve a megfelelő helyükre teszed a fájlokat (pontosabban az egy szem .desktop fájlt). 'xdg-*' nincs mindenhol telepítve, és nem mintha bármi mást csinálna, mint odarakja az is... (és nem mintha felülbíráhatná az xdg-* bármi másra, az xdg speckó elég szigorúan megköti, hogy csakis az /usr/share/applications vagy az /usr/local/share/applications jöhet szóba root általi telepítésnél, semmi más).

A third-party csomag minden részének lényegében az /opt-ba (és csak oda) szabad kerülnie az FHS szerint.

Tévedés, semmi ilyesmi nincs az FHS-ben! Honnan vetted ezt a marhaságot? Ezeknek a helye egyértelműen az /usr/local: "It [/usr/local] may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr."

hivatalosan még a /usr/local-ba sem írhatsz!

Újfent, honnan vetted ezt a marhaságot??? Az XDG speckó konkrétan így szól: "In case the /usr/share hierarchy is not writable it is recommended to use /usr/local/share as value for datadir instead. ". Az FHS szerint meg: "The /usr/local hierarchy is for use by the system administrator when installing software locally.".

nem értem, hogy a Debian rendszer (csomag?) megalkotói, hogy is képzelik el egy külső program beintegrálását a Linux rendszerbe! Egyrészt teljesen legyen elkülönítve, másrészt pedig legyen minden szinten szépen integrálva a linux-ba! Ráadásul mindezt úgy, hogy ehhez semmilyen támogatás sincs biztosítva.

Úgy látom, Neked az a legeslegnagyobb problémád, hogy tévképzetekben élsz, aminek semmi köze a valósághoz. Olvass specifikációkat, hogy leessen, mennyi mindenben tévedsz! Nem rocketscience ez, és a debian kifejezetten jól dokumentált.

Azért nem érted, mert hülyeségeket hordasz itt össze, ahelyett, hogy inkább elolvasnád a handbook-ot.

Tévedés, semmi ilyesmi nincs az FHS-ben! Honnan vetted ezt a marhaságot? Ezeknek a helye egyértelműen az /usr/local: "It [/usr/local] may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr."

Ezen azért még érdemes volna elmélázni egy kicsit, imho az FHS helyenként meglehetősen szar (mármint megfogalmazás ügyileg). Egyrészt valóban nincs benne az /opt-ról szóló fejezetben, hogy ez kötelező lenne, csak az, hogy erre van fenntartva, ami azért implikálja, hogy ezt oda kéne tenni alapvetően.

Másrészt az /usr/localnak az általad skippelt első két mondata az, hogy "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated"

Namost itt erős a kérdés, hogy vajon mi a faszt jelent, hogy use "by the system administrator when installing software locally". A locally része egész izgi, remotely ritkán telepít az ember szoftvert, hacsak nem ugye arról van szó, hogy mondjuk valami shared mount van. Az általad idézett mondat _szerintem_ pont ezt engedi meg mégis, nem önmagában értelmezendő. A másik izgi része a "by the system administraror": mivel ugye alapvetően mindent ő telepít (hiszen ő fog dpkg meg rpm parancsokat is kiadni), ezért a megkülönböztetés inkább arra vonatkozik, hogy a kicsi kezével (tehát mondjuk helyben fordítás után előállt, vagy más forrásból származó program), nem a "szokásos" módon telepített, ami ugye esetünkben a csomagkezelő. A következő it needs to be safe ... meg is erősíti, hogy a updatekor nem kéne felülbaszni system sofware upgradekor. És azon természetesen lehet vitatkozni, hogy most akkor a third party app az vajon system software-e (szerintem igen), de látszik, hogy a szándék bizony az, hogy ezt ne baszogtassa a rendszer.

Szóval bár elég szerencsétlen a megfogalmazás, de ezzel együtt szerintem itt azért alapvetően az van, hogy az /usr/local kézzel való turkálásra van, tehát a package manager ne nyúljon hozzá, az FHS pedig leírja, hogy az addonok helye a /opt, szóval de, tessék szépen odatenni. (És személy szerint pl bár értem, hogy pl a FreeBSD mivel indokolja, hogy mindent, ami nem szűken vett OS, az az /usr/localba tesz, de mindig is kreténségnek tartottam, pontosan azért, mert azt a biztonságot, hogy "amit ide tettem a kicsi kezemmel, azt biztosan nem bántja semmi" veri telibe keresztbe. A netbsdseknek volt annyi eszük, hogy ezeket eltegyék az /usr/pkg-be)

imho az FHS helyenként meglehetősen szar (mármint megfogalmazás ügyileg).

Ezt aláírom, valóban így van. Ez minden Microsoft specifikációra általánosságban igaz egyébként, kivéve az MSDN-t. (A félreértések elkerülése végett, az FHS az MS agyszüleménye, amit a Linux Foundation-ön keresztül publikáltak.)

A locally része egész izgi, remotely ritkán telepít az ember szoftvert

Félreérted. A remote itt azt jelenti, hogy egységes tárolóból, a disztró repójában található .deb-ből, míg a locally meg azt, hogy kézzel helyi .deb fájlból (vagy helyben fordított forrásból), tehát third-party szoftvert, ill. disztró tárolójában nem található verziójút telepíteni.

Szóval bár elég szerencsétlen a megfogalmazás, de ezzel együtt szerintem itt azért alapvetően az van, hogy az /usr/local kézzel való turkálásra van, tehát a package manager ne nyúljon hozzá

Igen, gázos a megfogalmazás, és pontosan emiatt ez a third-party appok helye (amiket a package managernek nem szabad csesztetnie, na de mivel third-partyk, azaz disztró repón kívüliek, így nem is tudja csesztetni őket, hisz nem szabadna, hogy tudomása legyen róluk).

Félreérted. A remote itt azt jelenti, hogy egységes tárolóból, a disztró repójában található .deb-ből, míg a locally meg azt, hogy kézzel helyi .deb fájlból (vagy helyben fordított forrásból), tehát third-party szoftvert, ill. disztró tárolójában nem található verziójút telepíteni.

Hát, nem igazán győztél meg. Eleve, az FHS nem foglalkozik means of deilveryvel, nem is biztos, hogy van csomagkezelő. Másrészt teljesen nonszensz az az elválasztás, hogy helyi deb, repoban levő deb. Ha leszedem kézzel, akkor hirtelen már az /usr/local alá kéne tenni?

Igen, gázos a megfogalmazás, és pontosan emiatt ez a third-party appok helye (amiket a package managernek nem szabad csesztetnie, na de mivel third-partyk, azaz disztró repón kívüliek, így nem is tudja csesztetni őket, hisz nem szabadna, hogy tudomása legyen róluk).

Ne viccelj már, hogy a package manager nem tud a third party packageról, amit vele telepítettek fel, jó eséllyel akár egy 3rd party repóból.

És ha a te logikád követjük, akkor ez se kötelező, hiszen ebbe sincs beleírva. Én akkor maradnék inkább annál, hogy oda teszem az extra packaget, ami a neki fenntartott hely, az adminnak fenntartott részt meg meghagyom az adminnak, hiszen az nem én vagyok.

- a csomag formai összerakását megcsinálja, de azt, hogy a fájl rendszerbe mi hova kerüljön azt nem. A debhelper abban is sokat segít, hogy (sok) mindent 'magától' a helyére rak!

- éppen ez a bajom a debhelperrel, hogy nem támogatja az /opt féle third-party csomagokat

- pl. azért nem működhet a direktbe való bele írás, mert mindenkinek le kell kódolni ugyanazt a logikát (ami teljesen felesleges, hibára ad lehetőséget) és ráadásul nem is rugalmas, nem tud követni egy későbbi specifikáció változást (ill. azt mindig neked kell kézzel utána húznod!)

- nem csak az egy szem desktop, hanem az összes ikon, menü és mime-type ill. azok rendszerbe illesztése (pl. cache update-k).

- az általad is belinkelt 'Add-on application' az FHS  §3.13 szerintem pont ezekre a 'third-party' szoftverekre vonatkozik. Legalábbis én így értelmezem, de javíts ki, ha nem! (Különben ezt neveztem én hitvitának: /usr/local vs. /opt. Az internet tele van pro és kontra állásfoglalásokkal!) Számomra kétségtelen előnye ennek a /usr/local felfogásnak, hogy ekkor a debhelper is jobban (ki)használható, hisz nem kell úgy elkülöníteni a külső programot. Szóval ez az egyik alapkérdés, amiben bizonytalan vagyok! Szerinted minek kellene az /opt-ba kerülnie?

- megint az alapkérdésnél vagyunk: ha az /opt-os filozófiát választod, akkor nem írhatsz az /opt-on kívülre

- rengeteg specifikációt olvastam és lehet, hogy éppen ez a baj. Valahogy nem állt össze a sok kis kép egy nagy egységes egészbe. Éppen ezért és ebben kértem segítséget és ebben lehet, hogy ez a mostani hozzá szólásod segített. Sok érvet soroltál fel a /usr/local filozófia mellett (ráadásul erre épül az eredeti megoldásom is), úgyhogy megpróbálom újra végig gondolni az egészet ezen szempontok alapján. Köszönöm!

- a csomag formai összerakását megcsinálja, de azt, hogy a fájl rendszerbe mi hova kerüljön azt nem. A debhelper abban is sokat segít, hogy (sok) mindent 'magától' a helyére rak!

- éppen ez a bajom a debhelperrel, hogy nem támogatja az /opt féle third-party csomagokat

Csak ismételni tudom magam. Annak, hogy Te rakod össze, pont az az előnye, hogy használhatsz akár /opt-ot is. De ne tedd, nem véletlen, hogy a debhelper sem támogatja. De ha nem használsz /opt-ot, akkor is megéri magad összerakni, mert függőségmentes lesz a workflow-d (pl. Gentoo vagy RedHat alatt is le lehet fordítani a cuccod .deb-é, ahol nincs is debhelper).

pl. azért nem működhet a direktbe való bele írás, mert mindenkinek le kell kódolni ugyanazt a logikát

Már meg ne haragudj, de mégis miről beszélsz? Semmiféle kódolásról nincs szó!!! A .deb egy adatfájl, aminek a szerkezete jól definiált. A kódolás része a dpkg-ban van, amit még véletlenül sem tartalmaz egyetlen .deb csomag se, azok csupán csak adatok! Amikor .deb fájlt csinálsz, semmiféle logikát nem kódolsz! (Max a csomag specifikus postinstall szkriptet, de az meg hát ugye, csomag specifikus szkript, csakis arra az adott egyetlen egy csomagra vonatkozik)

nem csak az egy szem desktop, hanem az összes ikon, menü és mime-type ill. azok rendszerbe illesztése (pl. cache update-k).

...amiknek a helyét az XDG specifikáció mind datadir relatívként definiálja, majd pedig azt mondja, hogy a datadir-nek /usr/share-nek (ill. /usr/local/share-nek) kell lennie. Az /opt nem szerepel az XDG specifikációban (csupán csak MergeFile példaként említi, hogy honnan másolódjon az /usr/share/applications alá a desktop fájl).

az általad is belinkelt 'Add-on application' az FHS §3.13 szerintem pont ezekre a 'third-party' szoftverekre vonatkozik. Legalábbis én így értelmezem, de javíts ki, ha nem!

Már kijavítottalak. Idézem mégegyszer: It [/usr/local] may be used for programs and data. Ezek miféle programok lennének, ha nem third-partyk?

Szerinted minek kellene az /opt-ba kerülnie?

Semminek. Debian alatt nem szokás /opt-ot használni, nem véletlen, hogy a debhelper sem támogatja.

Köszönöm!

Szívesen! Sok sikert! Ne félj magadtól összerakni a csomagokat, egyáltalán nem ördögtől való.

Csak ismételni tudom magam. Annak, hogy Te rakod össze, pont az az előnye, hogy használhatsz akár /opt-ot is. De ne tedd, nem véletlen, hogy a debhelper sem támogatja. De ha nem használsz /opt-ot, akkor is megéri magad összerakni, mert függőségmentes lesz a workflow-d (pl. Gentoo vagy RedHat alatt is le lehet fordítani a cuccod .deb-é, ahol nincs is debhelper).

Értem, amit mondasz, de ilyen alapon akár Intel assembly-ben is írhatnánk az applikációt, mert akkor az még az op. rendszertől is független lenne minden. Nem kötözködni akarok, csak mérlegelem az érveidet! (Különben - ilyen értelemben - a debhelper az /opt-ot sem támogatja.)

pl. azért nem működhet a direktbe való bele írás, mert mindenkinek le kell kódolni ugyanazt a logikát

Már meg ne haragudj, de mégis miről beszélsz? Semmiféle kódolásról nincs szó!!! A .deb egy adatfájl, aminek a szerkezete jól definiált. A kódolás része a dpkg-ban van, amit még véletlenül sem tartalmaz egyetlen .deb csomag se, azok csupán csak adatok! Amikor .deb fájlt csinálsz, semmiféle logikát nem kódolsz! (Max a csomag specifikus postinstall szkriptet, de az meg hát ugye, csomag specifikus szkript, csakis arra az adott egyetlen egy csomagra vonatkozik)

Kódolás alatt azt a logikát értem amivel pl. a dh_installman a man page-okat elhelyezi a nyelvnek megfelelő helyre a fájl struktúrában. De ilyen lehet akár azoknak a triggereknek és update/refresh mechanizmusoknak a használata is amivel pl. a cél gépre már felrakott adat fájlok beágyazás megtörténik az ottani rendszerbe, pl. cache fájlokba. Ezeknek az interface-k a használata azért jó, mert megvalósítanak és eltakarnak egy csomó részletet, amivel így neked nem kell foglalkozni.

az általad is belinkelt 'Add-on application' az FHS §3.13 szerintem pont ezekre a 'third-party' szoftverekre vonatkozik. Legalábbis én így értelmezem, de javíts ki, ha nem!

Már kijavítottalak. Idézem mégegyszer: It [/usr/local] may be used for programs and data. Ezek miféle programok lennének, ha nem third-partyk?

Látod éppen ez az egyik alap problémám! Akár az /opt akár a /usr/local megoldást nézzük, mindkettőnek valahogy az a lényege, hogy a third-party sw-ket szeparáljuk el a disztribúciótól, mert jobb a békesség: ne zavarják egymást! És ekkor most írjunk bele a fájl rendszer közepébe, akár direktbe, akár valamilyen tool-on keresztül! Ahogy már említettem, az /opt-os megoldásnál a man-page-k integrálása úgy van megoldva, hogy semmilyen 'behatást' nem kell eszközölni a disztribúcióba, hanem a man-page-k keresési algoritmusa kiterjed az /opt bizonyos helyeire is.

Szerinted minek kellene az /opt-ba kerülnie?

Semminek. Debian alatt nem szokás /opt-ot használni, nem véletlen, hogy a debhelper sem támogatja.

Éppen ilyen elveket, filozófiákat keresek, de ezt még soha sem láttam sehol sem leírva, kimondva!

Értem, amit mondasz, de ilyen alapon akár Intel assembly-ben is írhatnánk az applikációt, mert akkor az még az op. rendszertől is független lenne minden.

Szerintem nem érted, mert a példád ezer sebből vérzik. (Attól még, hogy assembly-ben írsz valamit, nem lesz op. rendszer független, sőt, pont hogy akkor vagy kénytelen használni az alacsonyszintű OS-függő ABI-t igazán, mint pl. SysV/fastcall, PLT call, DLL call, syscall, svc, int 0x80 stb. míg mondjuk egy C forrásnál nem kell tudod ezekről semmit se, ezért az portolható.)

Itt nem arról van szó, hogy "lemegyünk alacsony szintre", hanem arról van szó, hogy egy adatfájl előállításához a lehető legkevesebb, és legáltalánosabban elterjedt, alap utasításokat használjuk csak. Igen, ilyenkor nekünk kell odafigyelni, hogy helyes adatok kerüljenek bele, mert ezek a toolok csak a csomagolást végzik el nekünk, na de pont ez is a lényeg, hogy teljes kontrollal rendelkezzünk.

Kódolás alatt azt a logikát értem amivel pl. a dh_installman a man page-okat elhelyezi a nyelvnek megfelelő helyre a fájl struktúrában.

...és aminek semmi köze a deb fájlokhoz! Azokban nincs semmi sem tárolva dh_installman kódjából vagy logikájából.

De ilyen lehet akár azoknak a triggereknek és update/refresh mechanizmusoknak a használata is amivel pl. a cél gépre már felrakott adat fájlok beágyazás megtörténik az ottani rendszerbe, pl. cache fájlokba.

És újfent, ezek sem a deb fájlokban tárolódnak. Ami a deb-ben található, az max egy parancs hívása a postinst szkriptben, semmi több, magából a kódból és a logikájából semmi!

Ezeknek az interface-k a használata azért jó, mert megvalósítanak és eltakarnak egy csomó részletet, amivel így neked nem kell foglalkozni.

Na hát ez az! Nem pont te panaszkodtál arra, hogy mivel eltakarják a részletet, így kiveszik a kezedből a gyeplőt, és nem hagyják, hogy azt tegyél bele, amit szeretnél?

Döntened kell: vagy script-kiddie leszel vagy igazi hacker. Az első, a kék pirula kényelmes ugyan, de erősen limitált képességű; az utóbbi, a piros pirula rögösebb út és odafigyelést igényel, cserébe viszont teljesen szabad kezet ad mindenek felett.

Értem, amit mondasz, de ilyen alapon akár Intel assembly-ben is írhatnánk az applikációt, mert akkor az még az op. rendszertől is független lenne minden.

Szerintem nem érted, mert a példád ezer sebből vérzik. (Attól még, hogy assembly-ben írsz valamit, nem lesz op. rendszer független, sőt, pont hogy akkor vagy kénytelen használni az alacsonyszintű OS-függő ABI-t igazán, mint pl. SysV/fastcall, PLT call, DLL call, syscall, svc, int 0x80 stb. míg mondjuk egy C forrásnál nem kell tudod ezekről semmit se, ezért az portolható.)

Igazad van pontosítok: "Intel assembly-ben" --> "Intel assembly-ben direkt a vasra"

Itt nem arról van szó, hogy "lemegyünk alacsony szintre", hanem arról van szó, hogy egy adatfájl előállításához a lehető legkevesebb, és legáltalánosabban elterjedt, alap utasításokat használjuk csak. Igen, ilyenkor nekünk kell odafigyelni, hogy helyes adatok kerüljenek bele, mert ezek a toolok csak a csomagolást végzik el nekünk, na de pont ez is a lényeg, hogy teljes kontrollal rendelkezzünk.

Igen, de én "az adatfájl előállításához" is szeretnék tool-okat használni, mert azok egyszerűbbé, kényelmesebbé és időtállóbbá teszik a munkám.

Kódolás alatt azt a logikát értem amivel pl. a dh_installman a man page-okat elhelyezi a nyelvnek megfelelő helyre a fájl struktúrában.

...és aminek semmi köze a deb fájlokhoz! Azokban nincs semmi sem tárolva dh_installman kódjából vagy logikájából.

A .deb fájlokhoz semmi közük, de a tartalmuk előállításukhoz viszont igen.

De ilyen lehet akár azoknak a triggereknek és update/refresh mechanizmusoknak a használata is amivel pl. a cél gépre már felrakott adat fájlok beágyazás megtörténik az ottani rendszerbe, pl. cache fájlokba.

És újfent, ezek sem a deb fájlokban tárolódnak. Ami a deb-ben található, az max egy parancs hívása a postinst szkriptben, semmi több, magából a kódból és a logikájából semmi!

Pont ezekre gondolok és ezek a .deb-ben vannak: hol, mikor és mit kell meghívni.

Ezeknek az interface-k a használata azért jó, mert megvalósítanak és eltakarnak egy csomó részletet, amivel így neked nem kell foglalkozni.

Na hát ez az! Nem pont te panaszkodtál arra, hogy mivel eltakarják a részletet, így kiveszik a kezedből a gyeplőt, és nem hagyják, hogy azt tegyél bele, amit szeretnél?

Igen, így van, egyetértek veled. De ettől még lehetne egy jobban átgondolt és felépített script rendszer, ami támogat egy olyan alapvető funkciót mint egy külső csomag beágyazása a disztribúcióba.

Döntened kell: vagy script-kiddie leszel vagy igazi hacker. Az első, a kék pirula kényelmes ugyan, de erősen limitált képességű; az utóbbi, a piros pirula rögösebb út és odafigyelést igényel, cserébe viszont teljesen szabad kezet ad mindenek felett.

Igen, ebben is egyetértek veled. A különbség csak az, hogy én itt a script-kiddie alatt nem valami negatív dolgot értek, hanem egy elvárható minimumot, amit egy disztribúciónak nyújtani kellene.

------

Szóval maradt a nagy kérdés: hogy is kéne egy third-party .deb csomagnak kinéznie. Legyen jól elkülönülve, de azért szépen be is legyen ágyazva! Ahogy most látom, nem lehet teljesen elkülöníteni, mert ezt nem támogatja a disztribúció. Valamilyen technikával magának a csomagnak kell 'csápokat eresztenie' a disztribúció belsejébe, hogy odakösse magát.

Közben az /opt vs. /usr/local témához találtam egy gondolatot, amit szerintem érdemes elolvasni.

PS:

Köszönöm mindenkinek a jó szándékú segíteni akarást. Sok gondolat összejött, ami nekem segített a fejemben tisztázni dolgokat, de azért a témát nem tudtam megnyugtatóan lezárni.

Egyszerűen nem működhet úgy egy ilyen igen összetett rendszer, hogy mindenki - szinte ötletszerűen - 'direktbe' beír valamit valahova!

Mondjk a linux pont így működik. Scriptek, binárisok, csomagkezelők írkálnak direktbe mindenfele. Persze nem ötletszerűen és időnként meg kell hívni más programokat előtte vagy épp utána az elvárt eredmény eléréséhez...Pl az xdg-t

( chx | 2023. 11. 10., p – 16:53 )

Nem hitvita, egyben subs. Nem csomagkezelve ugyan, mi 3rd party sw-t (minden, ami nincs a repo-ban) mindig a /opt/akármi-sw alá teszünk Linuxon, és a /usr/akármi-sw vagy a /usr/IBM|ibm|whatever/akármi-sw alá AIX-en. Bár mára az utóbbi elkopott.
Az alkalmazás (indító, leállító, maintenance, check, patch stb.) scriptek a /usr/local/bin alatt.

echo crash > /dev/kmem

( Mik v | 2023. 11. 17., p – 12:12 )

Szerkesztve: 2023. 11. 17., p – 12:16

Nemide