Re: Utak lehetőségek a Puppy számára
Elküldve: 2020.08.15. 18:50
Ötlet fejlesztéshez:
A pet-elv a fejlesztési folyamathoz Git nélkül SF-en:
Volna egy kikupált alap iso. Ez felkerülne a fő projekt mappán belül lévő iso mappába. Ebbe lenne további 2 mappa kizárólag:
Tehát a fő projekt mappán belül lennének:
iso
pet
build
-iso mappa tartalma az előbb említett alap iso.
-pet mappa tartalma mindig az a pet csomag, amit telepítve ram vagy mentésfájl módban felülírja a rendszer azon részét amit futásidőben lehet. A skeleton iso ennek megfelelően olyan alapokat és javításokat kell tartalmazzon addigra, hogy ezt megtehessük.
-build mappa tartalmazná sorszámmal ellátva azon pet csomagokat, amelyeket a fejlesztők tesznek fel. Miért kell sorszám? Azért mert a 001_patch_nocsak.pet -et ha módosítani kellett úgy, hogy pl.: a 002_patch_ticoo1.pet benne bármit is felül kell írjon, akkor ezt a fejlesztők megtehessék ezáltal.
Akkor és amennyiben pl ha van 8 már LTS állapotban lévő pet a build mappában, akkor lehetne a pet mappába egybegyúrni őket 1 petté. A pet mappa pedig mindig az aktuálisan már javított egybegyúrt petet tartalmazná.
A sorszámozott petek egymással pedig úgy gyúrhatók össze, hogy mindegyiket külön mappájukba nevük alapján sorrendbe kibontva, felül írni egyenként sorrendben, tehát 001 pet kibontott mappájába beleírni a 002 mappa tartalmát, aztán ugyanide a 003-mat és ameddig a sorszámok tartanak. Utána ebből a fő mappából 1 nagy petet készíteni s ez menne a pet mappába…
Ha zárjuk a projektet, töröljük a build mappát, marad a véglegesített pet mappa és a skeleton iso
mappa.
Aki egybe készen kívánná az egészet pet nélkül, ahhoz biztosítani részletes dokumentációt, hogyan lehet belerakni a fő sfs-be egybe az egészet. Bár ebbe a mondatba le tudom írni úgy, hogy a kibontott, utolsó friss pet mappába lévő petet az egy ext fájlrenszerre kibontott adott puppy fő sfs-ébe belerakjuk, és vissza dir2sfs-ezvén az így kiegészült és kibontva levő fő sfs mappát megkapnánk így a fő sfs-t már kiegészítve. Ha pedig mindezt iso-ban szeretnénk viszontlátni, akkor ahhoz is egy dokumentációt bocsájtani, és kész. Bár az iso master programmal ezt is könnyen meg lehet oldani, ez már tényleg csak azon múlik mennyire pontos a leírás.
Indoklás: A fejlesztők így egymáshoz igazodva tudnák a módosításokat lekövetni és elkészíteni egy végeleges pupletet meghagyván a lehetőséget ahhoz, hogy választhasson a letöltő felhasználó az alap iso és a kész pet-tel kiegészíthető komplett verzió közül amit viszont már magának kéne az előbb leírt módszer szerint elkészítenie a felhasználónak. Továbbá az egyénileg fejlesztett pupletet is követhetőbbé tenné.
Miért jó ha a felhasználó nem készen kapja meg az iso-t summa benne mindennel. Erre az a válasz érkezett, hogy mert lehet valakinek a fele felesleges lesz és mérgelődne, hogy de lehetne anélkül kisebb is az iso. Stb. Nem tudunk minden igényt kielégíteni. És nem is hiszem, hogy lehet. Ez a módszer a fejlesztést szerintem megkönnyítené, és a user is választhatna a komplett és az alap közül. Aztán az alapot vagy maga tuningolja fel vagy pettel vagy anélkül. De a stabil alap meg lenne. És az extrák is opcionálisan. Ezzel pl.: a tárhely mérete sem iso-nként nőne minden módosításnál az SF-en. Az alap iso-val meg lehetne gparted és rendszermentő puppyként dolgozni. Ha meg fullos kell akkor eljárni az előbb leírt módokon. Ez csak egy (lehet banális) kósza ötlet volt, várom a véleményeteket!
Megjegyzés: A fejlesztési folyamatot kész iso-val is lehet zárni, itt a fejlesztési módszeren volna a fő hangsúly.
A pet-elv a fejlesztési folyamathoz Git nélkül SF-en:
Volna egy kikupált alap iso. Ez felkerülne a fő projekt mappán belül lévő iso mappába. Ebbe lenne további 2 mappa kizárólag:
Tehát a fő projekt mappán belül lennének:
iso
pet
build
-iso mappa tartalma az előbb említett alap iso.
-pet mappa tartalma mindig az a pet csomag, amit telepítve ram vagy mentésfájl módban felülírja a rendszer azon részét amit futásidőben lehet. A skeleton iso ennek megfelelően olyan alapokat és javításokat kell tartalmazzon addigra, hogy ezt megtehessük.
-build mappa tartalmazná sorszámmal ellátva azon pet csomagokat, amelyeket a fejlesztők tesznek fel. Miért kell sorszám? Azért mert a 001_patch_nocsak.pet -et ha módosítani kellett úgy, hogy pl.: a 002_patch_ticoo1.pet benne bármit is felül kell írjon, akkor ezt a fejlesztők megtehessék ezáltal.
Akkor és amennyiben pl ha van 8 már LTS állapotban lévő pet a build mappában, akkor lehetne a pet mappába egybegyúrni őket 1 petté. A pet mappa pedig mindig az aktuálisan már javított egybegyúrt petet tartalmazná.
A sorszámozott petek egymással pedig úgy gyúrhatók össze, hogy mindegyiket külön mappájukba nevük alapján sorrendbe kibontva, felül írni egyenként sorrendben, tehát 001 pet kibontott mappájába beleírni a 002 mappa tartalmát, aztán ugyanide a 003-mat és ameddig a sorszámok tartanak. Utána ebből a fő mappából 1 nagy petet készíteni s ez menne a pet mappába…
Ha zárjuk a projektet, töröljük a build mappát, marad a véglegesített pet mappa és a skeleton iso
mappa.
Aki egybe készen kívánná az egészet pet nélkül, ahhoz biztosítani részletes dokumentációt, hogyan lehet belerakni a fő sfs-be egybe az egészet. Bár ebbe a mondatba le tudom írni úgy, hogy a kibontott, utolsó friss pet mappába lévő petet az egy ext fájlrenszerre kibontott adott puppy fő sfs-ébe belerakjuk, és vissza dir2sfs-ezvén az így kiegészült és kibontva levő fő sfs mappát megkapnánk így a fő sfs-t már kiegészítve. Ha pedig mindezt iso-ban szeretnénk viszontlátni, akkor ahhoz is egy dokumentációt bocsájtani, és kész. Bár az iso master programmal ezt is könnyen meg lehet oldani, ez már tényleg csak azon múlik mennyire pontos a leírás.
Indoklás: A fejlesztők így egymáshoz igazodva tudnák a módosításokat lekövetni és elkészíteni egy végeleges pupletet meghagyván a lehetőséget ahhoz, hogy választhasson a letöltő felhasználó az alap iso és a kész pet-tel kiegészíthető komplett verzió közül amit viszont már magának kéne az előbb leírt módszer szerint elkészítenie a felhasználónak. Továbbá az egyénileg fejlesztett pupletet is követhetőbbé tenné.
Miért jó ha a felhasználó nem készen kapja meg az iso-t summa benne mindennel. Erre az a válasz érkezett, hogy mert lehet valakinek a fele felesleges lesz és mérgelődne, hogy de lehetne anélkül kisebb is az iso. Stb. Nem tudunk minden igényt kielégíteni. És nem is hiszem, hogy lehet. Ez a módszer a fejlesztést szerintem megkönnyítené, és a user is választhatna a komplett és az alap közül. Aztán az alapot vagy maga tuningolja fel vagy pettel vagy anélkül. De a stabil alap meg lenne. És az extrák is opcionálisan. Ezzel pl.: a tárhely mérete sem iso-nként nőne minden módosításnál az SF-en. Az alap iso-val meg lehetne gparted és rendszermentő puppyként dolgozni. Ha meg fullos kell akkor eljárni az előbb leírt módokon. Ez csak egy (lehet banális) kósza ötlet volt, várom a véleményeteket!
Megjegyzés: A fejlesztési folyamatot kész iso-val is lehet zárni, itt a fejlesztési módszeren volna a fő hangsúly.