Bash csomagkezelő készítés 2

Programozás - kezdő

Sziasztok.

Szeretném továbbfejleszteni kicsit a csomagkezelőmet. Arra gondoltam, lecserélem a "porg" külső programot. (A porg kezelte a telepített csomag verzióját és a programok törléséért). A forrásból telepített csomagokat a "make uninstall" -al lehet töröl. De ehez kell a forrás is amiből telepítve lett. A kérdésem ezzel kapcsolatba, hol található az infó ami alapján törölni lehet.
Másik amit még szeretnék még megcsinálni, multilib csomagkezelés. Az tudom, hogy 2x kell telepíteni a csomagot eltérő konfiggal (ez már modósítva is van). A problémám ezzel, hogy telepítettem a 32bit-el utána törölni kell a kipontott forrás amivel telepítve lett és újra ki kell bontani a forrás az új telepítésnél. Nem tudom, hogy egy sima "make clean" elég e a 2 futtatás között.
Első nekifutásba ezt a 2 amit szeretnék kivitelezni.

A segítséget előre is köszönöm.

( mn3monic v | 2015. 03. 02., h – 07:04 )

Egy élmény volt olvasni az írásod :)

( uzsolt v | 2015. 03. 02., h – 09:41 )

De ehez kell a forrás is amiből telepítve lett. A kérdésem ezzel kapcsolatba, hol található az infó ami alapján törölni lehet.

A forrásban. De talán elegendő a pár Makefile, amit generált. Meg persze nem minden program Makefile-jának van uninstall része.

Igen tudom. :)
Gondoltam is rá, hogy ott folytatom tovább. De mivel az eredeti továbfejlesztése, ezért nyitottam újat. Ha sikerülne kivonnom a porg közremüködését, akkor kevesebb "függösége" lenne a csomagkezelőmnek.
A porg nemcsak a csomagok törlésére használtam hanem a feltelepített csomag verzió-t is követtem. Erre azt találtam ki, hogy telepítésnél egy meghatározott helyre létrehoz egy filet. Törlésre viszont nincs ötletem.

( PP v | 2015. 03. 03., k – 11:39 )

Egyenlőre marad a porg a csomagkezelőm része. De viszont a multilib telepítésre nincs valakinek ötlete? Az rendben van, hogy 2x telepítek külön konfigal. De mindketőnél tiszta forrást kell használni. Milyen más modja van azon kívül, hogy törlöm a forrás és újra kibontom?

Akkor még mire gondolsz? Ha nem bízol a készítőben, hogy jól csinálta meg a 'make distclean'-t, akkor mi mást tehetsz, mint hogy nulláról kezded?
Esetleg ilyen tákolásokkal próbálkozhatsz: 


cd /usr/local/src
tar xfzv foo-7.1.tgz
touch foo-7.1-mark
...
cd /usr/local/src
find foo-7.1 -newer foo-7.1-mark -delete

( PP v | 2015. 03. 08., v – 14:32 )

Sziasztok.

Sikerült megoldást találnom a törlés ügybe. Szeretném kikérni a véleményeteket benne, szerintetek mennyire biztonságos és véleményetek szerint menyire használható. Tesztelni teszteltem és möködött és a rendszerbe se csinált kárt.
Következő kép csináltam.

find /* | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ -e ^/home/ > elötte.txt
configure
make
make install
find /* | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ -e ^/home/ > utána.txt
diff elötte.txt utána.txt > törlendő.txt

Ezek után, egy egyszerű script-el törölhető a csomag.

for i in $(grep ">" törlendő.txt | awk '{ print $2 }')
do
/bin/rm -fi $i
done

Mit szóltok ehez a módszerhez?

Csúnya, lassú, eléggé nagy hibalehetőségekkel bír, pl. képzeld el, hogy miközben telepítesz valamit, egy program létrehoz a home-könyvtáradban egy fájlt (pl. cache). Akkor ez is a csomag része lenne? Persze ki lehet hagyni a /home-ot is, de ilyen eset bármikor előfordulhat.
Ezért lenne jobb egy külön könyvtárba telepíteni, mert ott a listát semmi nem zavarja.

A bináris csomag úgy készül(zanzásítva), hogy a megadott paraméterek alapján a buildserver leforgatja a forráskódból a csomagot, majd a make install-nak ad egy DESTDIR=/valahova/ opciót. Ekkor a make install ebbe a könyvtárba telepít, úgy mintha a '/valami/' volna a '/'.

Ezt te is megtudod tenni, majd ebben a könyvtárra készítesz egy fájllistát. A bináris csomagokról is készül egy ilyen lista, ez alapján töröl a csomagkezelő. Na ezután te nem csomagolod a fájlokat deb-be, rpm-be, tgz-be, fpm-be, uhu-ba, vagy akármibe (bináris csomag esetén ez történik), hanem átmozgatod a /-be. Egyszerű és tiszta megoldás, jobb mintha telepítés előtt, meg után is átnyálaznád a könyvtárszerkezetet.

Az ideológai szempontot már elmondtam a v1.0-ban, azt kihagynám, viszont javasolnám, hogy ha már a lemez gyötrése mellett teszed le a garast, tedd egy picit hw- és időkímélőbben: 


find $(ls -d /* | grep -vw -F "proc
tmp
dev
home") > elotte.txt

tupírozva a kolléga által már említett -ctime-mal

és 


awk '/^>/ {system("rm -fi " $2)}' torlendo.txt

( PP v | 2015. 03. 16., h – 23:32 )

Szisztok.

Úgy döntöttem, amíg nem találok ki más megoldást, addig használom a "DESTDIR"-t. A telepítés rész rendben van, de a törléssel van egy kis gondom. A DESTDIR-el létrehozott mappa tartalmát beledobtam, egy uninstall file-ba "find" segítségével. A fileba belekerül a "/usr és a /usr/bin" is amit nem lenne bölcs dolog letörölni. Úgyebár, ha "rm -rf ..." -et használom akkor törli a mappát is. Ha a file-kat törlöm, akkor minden letörölt csomag után ott marad a létrehozott mappák. Hogyan tudnám elérni, hogy csak azokat a mappákat törölje amiket a telepítés során hozott létre? A meglévő mappákból csak a filet törölje.

( PP v | 2015. 04. 04., szo – 21:37 )

Sziasztok.
Mivel visszatértem az Lfs linuxhoz folytatom a kis csomagkezelőmet. Annyival módosult, hogy multib kezel.(mivel a rendszerem is multilibes). Az elgondolásom megvan hogyan vitelezem ki. Kicsit bosszant a függőség kezelés. Esetleg nincs valakinek egy jó ötleted rá?

( PP v | 2015. 04. 10., p – 23:44 )

Sziasztok !

Találtam egy nagyon jó process bar-t, amit szeretnék felhasználni a csomagkezelőmnél. Csak sajnos, fogalmam sincs hogyan tudnám összehozni az update sript-el.

procesbar így nézz ki:
#!/bin/bash
let _progress=(${1}*100/${2}*100)/100
let _done=(${_progress}*4)/10
let _left=40-$_done
_fill=$(printf "%${_done}s")
_empty=$(printf "%${_left}s")

printf "\rProgress : [${_fill// /#}${_empty// /-}] ${_progress}%%"

}

_start=1

_end=100

for number in $(seq ${_start} ${_end})
do
sleep 0.1
ProgressBar ${number} ${_end}
done
printf '\nFinished!\n'

Update script:
source="/usr/bashpkg/sources"
pkgversion="/usr/bashpkg/pkgversions"

ver=$(curl -L -s http://ftp.midnight-commander.org/ | sed -rn '/href="mc/ s@.*a href="(mc-[^"]*.tar.gz).*@\1@p' | sort -V | tail -n 1)
echo "http://ftp.midnight-commander.org/" >> $source
echo "$ver" >> $pkgversion

ver=$(curl -L -s http://ftp.gnu.org/gnu/nano/ | sed -rn '/href="nano/ s@.*a href="(nano-[^"]*.tar.gz).*@\1@p' | sort -V)"
echo "http://ftp.gnu.org/gnu/nano/" >> $source
echo "$ver" >> $pkgversion

Megoldva !

#!/bin/bash

function ProgressBar {
let _progress=(${1}*100/${2}*100)/100
let _done=(${_progress}*4)/10
let _left=40-$_done
_fill=$(printf "%${_done}s")
_empty=$(printf "%${_left}s")
printf "\rCsomag frissítés : [${_fill// /#}${_empty// /-}] ${_progress}%%"
}

numberofqueries=2
queriesdone=0

function ProgressNext {
let queriesdone=queriesdone+1
ProgressBar $queriesdone $numberofqueries
}

####lekérdezés

pkgversion="/home/pusztito/Csomagkezelő/pkgversions"
source="/home/pusztito/Csomagkezelő/pkgsources"

ver=$(curl -L -s http://ftp.midnight-commander.org/ | sed -rn '/href="mc/ s@.*a href="(mc-[^"]*.tar.gz).*@\1@p' | sort -V | tail -n 1)
echo "http://ftp.midnight-commander.org/" >> $source
echo "$ver" >> $pkgversion
ProgressNext

ver=$(curl -L -s http://ftp.gnu.org/gnu/nano/ | sed -rn '/href="nano/ s@.*a href="(nano-[^"]*.tar.gz).*@\1@p' | sort -V)
echo "http://ftp.gnu.org/gnu/nano/" >> $source
ProgressNext

stb...

Attol fugg. Ami biztos, a konfiguracios fajlokat specialisan kell kezelni, hiszen azt senki sem szeretne, ha frissites utan defaultokkal jonne fel pl. a Samba.

A leggyorsabb megoldas talan osszediffelni a fajllistakat, es kiszedni az azonosakat, ami csak a regiben van meg (es nem konfig) az kuka, ami csak az ujban, az meg install.

Viszont, egy fokkal bonyolultabb kerdes az osztott konyvtarak kore. Ha valamiert valahol tortenik egy ABI valtas, akkor ha hirtelen kihuzod a dinamikus konyvtarakat, akkor annak konnyen szomoru vege lehet. A topic itt van kisse koruljarva: https://wiki.gentoo.org/wiki/Preserve-libs.

A legspecialisabb esete ennek a dist-upgrade + glibc temakor. Ha ugy huzod ki a glibc-t, hogy kozben meg nem minden csomag lett az ujra frissitve, abbol konnyen buko lehet. Cserebe akkor is, ha meg a programokat elobb frissited, mint a glibc-t.
--
Blog | @hron84
Üzemeltető macik

Az az ötletem többször felmerült már, hogy nem értem, miért akarod újra feltalálni a meleg vizet, raadásul úgy a szakértelemmel, mint a hozzáállással problémák látszanak adódni. Tudom, hogy nem okvetlen voltam konstruktív, legalábbis nem szakmailag - nézd el, kérlek!
------------------------
Program terminated
{0} ok boto
boto ?

Ez egyszerű. Próbálok egyedi csomagkezelőt csinálni és nem egy rpm, pacman vagy emerge-t Bash programnyelvbe megírni. Nem akarom publikálni mielött féreértenétek. Kizárolag, saját célra készűl.
Elismerem, van olyan megoldás, amit innen onnan nyúltam. De igyekszem "egyedi maradni."

Engedd meg, hogy még egy keveset akadékoskodjak: scriptek írását megtanulni szerintem ennél triviálisabb problémák megoldása során célszerűbb - ha pedig a felhasználási szándék a cél ehelyett, úgy az merül fel bennem, hogy ha szüksége lenne az LFS-nek egy csomagkezelőre, úgy valószínűleg rendelkezne vele... Ha pedig _neked_ van, miért nem használsz olyan disztribúciót, aminek van, vagy hasznosítod újra mások munkáját például pkgsrc használata által? Még említik is ráadásul... (Disclaimer: én SmartOS-en használom; korábban Solarison használtam, és nagyon jónak találom. Linuxon a portage a barátom.)
------------------------
Program terminated
{0} ok boto
boto ?

Nem feltétlen van szükségem, komplet csomagkezelőre. Max a rendszer frissítésnél jönne jól, amihez nem feltétlen van szükség. Elég lenne egy csomag frissítés figyelő script (már megvan). Útána már csak letölteni és telepíteni kell. Mondjuk, ezt már a "csomagkezelőm" már elvégzi helyettem. Amint mondtam, ötleteket és megoldásokat szoktam innen onnan "összelopkodni".

csinalj egy doinst.sh scriptet amit a csomagkezelod lefuttat a csomag telepitesekor.

Az akabbi egy pelda az lxdm csomagbol (slackware)


bash-4.2$ cat doinst.sh
config() {
NEW="$1"
OLD="$(dirname $NEW)/$(basename $NEW .new)"
# If there's no config file by that name, mv it over:
if [ ! -r $OLD ]; then
mv $NEW $OLD
elif [ "$(cat $OLD | md5sum)" = "$(cat $NEW | md5sum)" ]; then
# toss the redundant copy
rm $NEW
fi
# Otherwise, we leave the .new copy for the admin to consider...
}

config etc/lxdm/LoginReady.new
config etc/lxdm/PostLogin.new
config etc/lxdm/PostLogout.new
config etc/lxdm/PreLogin.new
config etc/lxdm/PreReboot.new
config etc/lxdm/PreShutdown.new
config etc/lxdm/lxdm.conf.new
config etc/lxdm/xinitrc.new

( PP v | 2015. 04. 18., szo – 04:07 )

Sziasztok.

Lenne egy olyan kérdésem, hogy milyen kiterjesztések szoktak lenni egy csomag konfig file-nak. Az /etc-ben a ".cfg és .conf" ezen kívül milyen kiterjesztés van? Arra gondoltam, hogy minden csomag telepítésnél leelenörzi, él e a file. Ha igen, akkor azt telepíti.

Minden csomagnal definialod a konfig fajlok nevet, es azt ellenorzi? Linuxon nem leteznek kiterjesztesek, legalabbis nem ugy, mint Windowson, a kiterjesztes itt csak a fajlnev resze, semmi tobb, nem jelent semmit. Ha valami fajlnak a neve valami_cfg annak latszolag nincs kiterjesztese, de ettol meg ugyanugy konfig fajl.

Tessek szepen a csomag scriptjebe kezzel beirkalni a neveket. Sok lehet, raadasul lehetnek almappak is. Okolszabalykent elmondhato, hogy minden, ami a /etc ala kerul, az 95%-ban konfig fajl, fuggetlenul a nevetol.
--
Blog | @hron84
Üzemeltető macik

( PP v | 2015. 07. 08., sze – 16:44 )

Sziasztok.

Egy kis pihenő után, ismét folytatom a csomagkezelőmet. Jelenleg, a függöségkezeléssel foglalkozom. Van egy ötletem, és szeretném kikérni a véleményeteket és a kivitelezésbe a segítségeteket.
Az ötlet a következő: Minden konfig fileba lenne egy változó pl: depend néven. Itt található a függöségek. Minden telepítés elött a progi leelenörizné a depend részt és mondjuk belerakhatná egy fileba.
Ha esetleg valamelyik hiányzik hozzávehetné a telepítéshez.

Igen, kb. ez a fuggosegkezeles definicioja, amit leirtal.

A neheze nem is ez, hanem kitalalni a feltelepitesi sorrendet, ugyanis van, amikor a postinst folyamat mar az eppen telepitett csomagbol kell elinditson eszkozoket, vagyis az osszes fuggosegenek fenn kell lenni.

Namost, ha nem epp az utolso csomagot telepited, akkor ez trukkos dolog, mert nem eleg csak az alap fuggosegi sorrend alapjan feltolni a csomagokat, hanem fel kell epiteni a fuggosegi fat, es a szerint sorbarakni, mindig a fa gyokerehez legkozelebb eso csomopontot lebontani (asszem igy mondjak), vagyis azokat kell elobb feltelepiteni, amitol a tobbi feltelepitett csomag egyszerre fugg.

Ez eleg bonyolult is lehet. Vegyunk egy alap (felig-meddig hasbol vett) peldat. Az akonadi csomag fugg a MySQL-tol es a libkde4 konyvtartol, a MySQL fugg a cmake-tol, a libkde4 es a cmake fugg a glib-tol, az pedig a gettext-tol. Ekkor (ha felteszem, hogy ez a teljes fuggosegi fa) eloszor fel kell rakni a gettext-et es a glib-et, utana a cmake-t, a libkde4-et, a MySQL-t es vegul az akonadit. Ez igy fejben egyszerunek tunik, de azt az algoritmust, ami vegig megy a fuggosegeken, es osszeallitja a telepitesi sorrendet - na azt nem trivialis megirni, foleg bash-ban nem. Nem veletlen, hogy a megoly bash-orientalt Gentoo-ban is python scriptet hivnak segitsegul a fuggosegi fa kiszamitasahoz.
--
Blog | @hron84
Üzemeltető macik

( PP v | 2015. 07. 11., szo – 10:39 )

Eljátszottam a gondolottal, mi lenne ha egy már megévő csomagkezelő közül választanék egyet és azt egészíteném ki saját script-el. Pl: ha bináris csomagkezelőt veszek alapúl, akkor lehetne egy script ami leelenörzi a friss csomagok forrássát és elkészíti számomra a bináris csomagot automatikusan.
Viszont azt nem tudom, hogy ilyenkor is kell függöségi fát készíteni?

( PP v | 2015. 11. 04., sze – 07:29 )

Sziasztok!

Újból nekiestem, a csomagkezelőnek. Mostani verziót multilibre szeretném csinálni. Ki is találtam, hogyan fogom ezt megvalósítani. Arra gondoltam, hogy 2 külön mappába fogom rakni a config file-at. Abba is módosítom a csomagkezelőmet, hogy nem külön file fogja tartalmazni a csomagok szerverrét. Sajnos, belefutottam egy problémába. Volt pár olyan csomag amit telepítésnél nem talált. Ezért a config file-ba ragtam a szervert. Simán változó tartalmazza a szervert. Ezzel viszont akadt egy problémám. Mégpedig a következő:

--2015-11-06 08:42:52-- http://ftp.midnight-commander.org/%22mc-4.8.14.tar.xz
Resolving ftp.midnight-commander.org... 64.50.233.100, 64.50.236.52
Connecting to ftp.midnight-commander.org|64.50.233.100|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-11-06 08:42:53 ERROR 404: Not Found.

Amint látjátok, van egy "%22" rész a csomagnév után. Viszont nem értem, hogy miért kerül oda.

SOURCE="$HOME/.bashpkg/sources"

for m in $(cat $CONF64/$PACKNAME.cfg | grep "mirror" | sed 's/\mirror=//; s/\"//'); do
for v in $(cat $VERSION | grep "$PACKNAME"); do
cd $SOURCE
printf "\n%6s\n\n" "Csomag letöltés"
sleep 2
wget $m$v
done
done

A kérdésem az, hogy miért egészítette ki?

( PP v | 2015. 11. 30., h – 14:29 )

Sziasztok !

Egy kis segítség kéne. Csomag konfig lefuttatás útán leelenörzi a csomag létrejöttét. A következő kép néz ki.

if [ -n $(ls $INSTALL64 | grep "$PACKNAME") ]; then
printf "\e[31m\n%6s\n\n\e[0m" "Nem jött létre csomag"
exit 1
else
printf "\e[32m\n%6s\n\n\e[0m" "Csomag telepítés..."
cp $INSTALL/$PACKNAME-*.*/*.* /
fi

AZ "INSTALL64" változó tartalma: "INSTALL64="$home/.bashpkg/package/64bit""

A problémám az, hogy nem találja a ".bashpkg/package/64bit" kövtárat. Terminálba viszont jó. Csomag is megtalálható a könyvtárba. Több helyen is ellenörzöm a könytárakat de mindenhol jó csak itt nem. Mi lehet az oka?

( PP v | 2015. 12. 07., h – 15:20 )

Sziasztok.

Ismét a segítségeteket kérném. Eddig a porg-ot használtam a csomagok törlésére és verzió követésre, most viszont kiszeretném hagyni a multilib verzióból. A közvetlen csomagtelepítés is kihagyom, helyette a "MAKEDIST"-et használom. A problémám a következő: Szépen létrehozom a csomagot a megadott helyre, cp-vel átmásolom, a gyökérkönyvtárba, de a verzió ellenörzés szerint nem cserélödött le a csomag. A mc csomaggel tesztelem a csomagkezelőmet. Jelenlegi verzió(ami telepítve van) 4.8.14 amit telepítek 4.8.15 ez a legfrissebb a csomagkezelőm szerint. Másolás kimenete az utolsó néhány sora:

'/root/.bashpkg/package/64bit/mc/./usr/local/etc/mc/mc.menu' -> '/./usr/local/etc/mc/mc.menu'
'/root/.bashpkg/package/64bit/mc/./usr/local/etc/mc/mc.menu.sr' -> '/./usr/local/etc/mc/mc.menu.sr'
'/root/.bashpkg/package/64bit/mc/./usr/local/etc/mc/mcedit.menu' -> '/./usr/local/etc/mc/mcedit.menu'
'/root/.bashpkg/package/64bit/mc/./usr/local/etc/mc/mc.ext' -> '/./usr/local/etc/mc/mc.ext'
'/root/.bashpkg/package/64bit/mc/./usr/local/etc/mc/edit.indent.rc' -> '/./usr/local/etc/mc/edit.indent.rc'
'/root/.bashpkg/package/64bit/mc/./usr/local/bin/mc' -> '/./usr/local/bin/mc'
removed '/./usr/local/bin/mcview'
'/root/.bashpkg/package/64bit/mc/./usr/local/bin/mcview' -> '/./usr/local/bin/mcview'
removed '/./usr/local/bin/mcedit'
'/root/.bashpkg/package/64bit/mc/./usr/local/bin/mcedit' -> '/./usr/local/bin/mcedit'
removed '/./usr/local/bin/mcdiff'
'/root/.bashpkg/package/64bit/mc/./usr/local/bin/mcdiff' -> '/./usr/local/bin/mcdiff'

Az ehez tartozó scrit rész:

if [ -z $(ls $INSTALL64 | grep "$PACKNAME") ]; then
printf "\e[31m\n%6s\n\n\e[0m" "Nem jött létre a csomag."
exit 1
else
printf "\e[32m\n%6s\n\n\e[0m" "64bit csomag telepítés."
sleep 1
cp -Rvf $INSTALL64/$PACKNAME/. /
fi

Nenenene. Miert ls? Miert nem lehet siman csak 


if [ -d "$INSTALL64/$PACKNAME" ] ; then

Az ls-grep parossal egy csomo hibalehetoseget behozol.

A cp -nel en ajanlom a p es P kapcsolok hasznalatat is.

Amugy kerdes, a verzioellenorzes hogyna ellenorzi a telepitett verziot?
--
Blog | @hron84
Üzemeltető macik

Még az a rész nincs meg. A terv az, hogy a remove mappába lesz a feltelepített csomagok amit törlésre és ellenörzésre is használni fogok. A cp-nél ha berakom a p P -t akkor a következő hibaüzenetett kapom.
"cp: omitting directory '/root/.bashpkg/package/64bit/mc/.'"

Szerk: Jelenleg a az mc --version módon.

A csomagkezelőbe a verzió ellenörzés még nincs benne. Most úgy teszteltem, hogy terminálba beírtam "mc --version".
Egyébként, elvégzi a csomagkezelő a feladatát. Annyi a gond, hogy a rendszer amint tesztelem, ott a csomagok telepítésénél a "prefix=/usr" lett használva. Szóval, az inditó file az /usr/bin -ba található. A csomagkezelőmnél az "usr/local/bin" -be van. Arra gondoltam, hogy átlinkelem az "usr/local/bin" -ből az "usr/bin" -be. A kérdésem a következő: Okozhat ez valami problémát? Mennyire lehet ezt álltalánosítani?

Nem mindent töröltem. Kínos, de rossz konfig file-t módosítottam. Véletlen, a felhasználó könyvtárba lévőt lett módosítva nem a root könytáré. Most már müködik. Maga a telepítés jó már csak a multilib funcíót kell kiprobálnom. Délután ha megjövök a melóból csinálok hamar egy olyan csomagot, aminek kell a 32bit libek is. Ha ez is jól müködik, akkor mehet a módosított verzió követő is. Oda még ki kell találnom, hogyan volna jó. Mostani verzióba nem külön file tartalmazza a szervert és a szerverről nyert verziót hanem a config fileba van benne. Azt viszont még nem tudom, hogy a verziót nem e lenne érdemes beledobni egy fileba vagy így is kinyerhető. Jelenleg így néz ki egy config file:

#!/bin/bash

home="https://www.midnight-commander.org"
ver=$(curl -L -s http://ftp.midnight-commander.org/ | sed -rn '/href="mc/ s@.*a href="(mc-[^"]*.tar.xz).*@\1@p' | sed 's/\.tar\.xz//' | sort -V | tail -n 1)
mirror="http://ftp.midnight-commander.org/"

##########

./configure --prefix=/usr
if [ $? -ne 0 ]; then

printf "%6s" "A 'configure' parancs hibássan futott le !!"
exit 1
fi

make

if [ $? -ne 0 ]; then
printf "%6s" "A 'make' parancs hibássan futott le !!"
exit 1
fi

make install DESTDIR=$HOME/.bashpkg/package/64bit/mc

Off:Az érdekesség kedvéért én is beszúrom a mc-fordító scriptem: 


PATH=/usr/local/bin:$PATH

if [ ! -f lib/tty/tty.cold ]; then cp -a lib/tty/tty.c lib/tty/tty.cold 
else				   cp -a lib/tty/tty.cold lib/tty/tty.c
fi

(
set -x
cd lib/tty
cat >tty.patch <<DONE
111a112
>         || strncmp (termvalue, "putty", 5) == 0
DONE
patch -i tty.patch tty.c
) 2>&1 | tee log.patch

make clean

set -e

export CFLAGS="$COMMON_CFLAGS32"
export CPPFLAGS="$COMMON_CPPFLAGS"
export LDFLAGS="$COMMON_LDFLAGS32"

./configure		\
    --enable-shared	\
    --enable-static	\
    --prefix=/usr/local \
    --without-x		\
    --with-screen=slang \
    --without-gpm-mouse	\
    --enable-nls	\
    --enable-extcharset \
2>&1 | tee log.configure

(make V=1 all && make install) 2>&1 | tee log.make

Köszi az érdekességet. Sajnos, ejtettem egy kis hibát, aminek súlyos következménye lett. Véletlen a törléshez hozzá adtam egy "-r" kapcsolot aminek az eredménye a "/usr" könyvtár törlése volt. Szerencsére, volt az alap rendszerről egy tömörítéssem, úgyhogy csak az xorg-től kellett újraépíteni a rendszert.Még egy kis finomhangolás és kész ismét.

( PP v | 2015. 12. 20., v – 19:10 )

Sziasztok !

Egy kis segítség kéne. Hogyan tudom, a config file-ból úgy kiolvasni egy változót, hogy ne a tartalmát hanem a változó értékét kapjam meg? Változó:

ver=$(curl -L -s http://ftp.midnight-commander.org/ | sed -rn '/href="mc/ s@.*a href="(mc-[^"]*.tar.gz).*@\1@p' | sort -V | tail -n 1)

A ver változó eredményét szeretném kinyerni.

Arra gondoltam, hogy nem csinálok külön fileokat a frisssítéshez. Eddig úgy volt, hogy volt egy "source" file és egy pkgversion file. A source file tartalmazta a csomagok elérését(servert) a pkgversion az elérhető legujabb csomagot. Mivel a source filet megszüntettem (belekerült a config fileba) úgy gondoltam, a friss csomag verzió is bekerül.
Azt szeretném elérni, hogy olvassa ki a "mirror" változót és a "ver" változót. Ennek a kettő értéknek az összerakásával töltöm le a friss csomagot. Így nézz ki a két változó:

home="https://www.midnight-commander.org"
ver=$(curl -L -s http://ftp.midnight-commander.org/ | sed -rn '/href="mc/ s@.*a href="(mc-[^"]*.tar.xz).*@\1@p' | sed 's/\.tar\.xz//' | sort -V | tail -n 1)

A mirror változót így olvasom ki. "sed -rn '/mirror/ s/(\mirror=|\")//pg' $CONF64/$PACKNAME.cfg" ez okés. De a ver valtozó értékét szeretném kiolvasni és behelyetesíteni.

(Hidd el nekem becsszóra, nem kapsz semmilyen prémiumot azért, mert egyetlen változó-értékadásba zsúfolsz bele egy komplett script-nyi teendőt... (off: ami azt illeti, ez tipikusan azokra jellemző, akik éppen meghaladták a kezdő szintet, és most a kódolás istencsászárainak érzik magukat))

A config fájlodban, csak változók vannak, vagy műveletet is hajt végre? Benne van a build is? Ha igen, szerintem úgy kéne megírnod a config fájlt, hogy csak változókat tartalmaz, a build rész meg egy fügvény, amit ha fordítani akarod a csomagod meghívsz. Ha így teszel, akkor tudsz írni egy szkriptet, pl:

show_ver.sh:
source $path/$1/config
echo $ver

használat: $ show_ver.sh "csomag-neve"

Javaslom nézegess egy PKGBUILD-et arch linux oldalán, az elég olvasható, és könnyen értelmezhető. De nekem jobban tetszik a FrugalBuild, azt is nézegethetsz a frugalware oldalán, na az már elsőre bonyolultabb, de ha megérted tök jó. Nem azért mondom hogy lemásold, csak hogy inspiráljon.

Szerk.: ja és akkor így simán tudnád olvasni a mirror-t is: echo $mirror. Ha már változót adsz meg rá.

Javaslom nézegess egy PKGBUILD-et arch linux oldalán, az elég olvasható, és könnyen értelmezhető. De nekem jobban tetszik a FrugalBuild, azt is nézegethetsz a frugalware oldalán, na az már elsőre bonyolultabb, de ha megérted tök jó.

Az "első részben" már többen javasoltuk.

Nyilván tanulni akar és saját utat bejárni, csakhogy a végeredmény majdnem ugyanaz lesz. Nem véletlen hogy a specs, ebuild, PKGBUILD, FrugalBuild, stb szinte ugyanaz, csak mások a függvények nevei, meg más sorrendben vannak a infók benne. Biztos vagyok benne, hogy legvégül ő is pont oda fog eljutni, csak a saját útján. De valaki azt mondta nem a cél a lényeg, hanem a bejárt út :P

A FrugalBuild annyival is jobb, mint a PKGBUILD, hogy van verzió követés, cserébe mondjuk bonyolultabb, teli van függvényekkel, nem a natur parancsot látod, kicsit rejtve van a lényeg. Frugalware scriptjeit a source/include könyvtárban találod, az util.sh a default, ha érdekel azzal kezdd a nézelődést.

NevemTeve válasz:

Elöző változatba külön csináltam. Volt egy "pkgupdate nevezetű scriptpl:

ver=$(curl -L -s http://ftp.midnight-commander.org/ | sed -rn '/href="mc/ s@.*a href="(mc-[^"]*.tar.gz).*@\1@p' | sort -V | tail -n 1)
echo "http://ftp.midnight-commander.org/" >> $source
echo "$ver" >> $pkgversion

Így ment szép sorba minden csomagnál. Ez remekül müködött a legtöbb csomagnál. Az volt a baj, hogy a mondjuk az "mc"-t akartam telepíteni, akkor nem találta a forrást. Itt a fügvény ami felelt a letöltésért.

download() {
for s in $(cat $FTP | grep "$PACKNAME"); do
for v in $(cat $VERSION | grep "$PACKNAME");do
cd $SOURCE
wget $s$v
done
done
}

kikadff válasz:

A konfig file tartalmazza a forgatáshoz szükséges parancsokat is.

#!/bin/bash

home="https://www.midnight-commander.org"
ver=$(curl -L -s http://ftp.midnight-commander.org/ | sed -rn '/href="mc/ s@.*a href="(mc-[^"]*.tar.xz).*@\1@p' | sed 's/\.tar\.xz//' | sort -V | tail -n 1)
mirror="http://ftp.midnight-commander.org/"

##########

./configure --prefix=/usr
if [ $? -ne 0 ]; then

printf "%6s" "A 'configure' parancs hibássan futott le !!"
exit 1
fi

make

if [ $? -ne 0 ]; then
printf "%6s" "A 'make' parancs hibássan futott le !!"
exit 1
fi

make install DESTDIR=$HOME/.bashpkg/package/64bit/mc

Ez a konfig file még csak kezdegleges

A konfig fájlban ne legyen művelet, hanem csak változó és függvény.

A forgatáshoz használt részt tedd egy függvénybe, pl forgatas() {
....
}

Ezután source-val beilleszted a konfig fájlod tartalmát a download scriptbe, és így tudni fogja a változók értékét.
Azt kell megoldanod, hogy a download scripted univerzális legyen, azaz fusson úgy hogy download.sh CSOMAGNEVE. A csomagneve az 1 változó lesz, így írd: source $path/$1/konfig, így a letölteni kívánt csomag konfigfájlját fogja beilleszteni és a megfelelő verzió stb változót fogod megkapni.

A forgatáshoz használj egy külön scripted, amibe ugyan ilyen logikával illesztet be a konfig fájlt, így a szkriptben simán használhatod a forgatas függvényt, mintha egy parancs lenne. Így többet nem kell bántanod a forgatáshoz készült scriptet, mert mindig a konfig fájlban megadott egyedi fordítási műveletet hajtja végre.

A source egy parancs, amiről én beszélek, nem a változó amiben a csomag forrásának letöltési útja van.

Ha egy scripte berakod ezt a sort:
source /usr/local/akarmi/mc/konfig

akkor amikor végrehajtódik a script, ez után a parancs után beilleszti a source /usr/local/akarmi/mc/konfig fájl tartalmát.

Így ha abban szerepelnek az adott csomag egyedi változói, forgatási függvénye, azt a továbbiakban a szkripted eltudja érni.

Tudni fogja mi a mc-hez tartozó $ver, $mirror, stb, tudni fogja hogyan kell lefordítani.

Valahogy így gondoltad? A config file-t?

#!/bash/bin

home="https://www.midnight-commander.org"
ver=$(curl -L -s http://ftp.midnight-commander.org/ | sed -rn '/href="mc/ s@.*a href="(mc-[^"]*.tar.xz).*@\1@p' | sed 's/\.tar\.xz//' | sort -V | tail -n 1)
mirror="http://ftp.midnight-commander.org/"

conf() {
./configure --prefix=/usr \
--sysconfdir=/etc \
--enable-charset &&
make
}
install() {
make install
cp -v doc/keybind-migration.txt /usr/share/mc
}

conf
if [ $? -ne 0 ]; then
printf "%6s" "A 'configure' parancs hibássan futott le !!"
exit 1
fi

install
if [ $? -ne 0 ]; then
printf "%6s" "A 'make' parancs hibássan futott le !!"
exit 1
fi

A függvényekig igen. De aztán a végrehajtást egy másik scriptbe tedd, amibe beilleszted a source-val a config fájlt.

fordits.sh:
-------------------------------------
#/bin/bash

source /ahol/neked/van/$1/config

conf
if [ $? -ne 0 ]; then
printf "%6s" "A 'configure' parancs hibássan futott le !!"
exit 1
fi

install
if [ $? -ne 0 ]; then
printf "%6s" "A 'make' parancs hibássan futott le !!"
exit 1
fi
--------------------------------

használata:
fordits.sh mc

Gyakorlatilag lesz pár scripted, amivel fordítod a csomagot, amivel lekérdezed van-e új verzió az adott csomagból. stb. Mindegyikbe beilleszted az adott config fájlt a 'source' paranccsal. Ezeket azután hogy megírot kb. soha többet nem kell piszkáld, csak a config fájlt, ha változtatsz valamit.

Ha egyszerre akarsz minden csomagot ellenőrizni (pl. miből van újabb verzió?) akkor csak egy for ciklusba teszed a scripted:

for i in $(ls /ahol/neked/vannak/); do
verziellenorzo.sh $i
done

A kimenetet meg úgy formázod ahogy neked tetszik.

Most már nagyon szúrja a szemem, így grammarnáci üzemmód: a "hibásan" egy "s". Ha két s-sel írod, akkor hibásan írod.

De amit én javasoltam (meg kikadff is szerintem), hogy a conf() függvény legyen egy külön, általánosan használt fájlban, amit mindig behúzol a source paranccsal (persze lehet csinálni egy build-package szkriptet, ami ezt megteszi, és nem kell minden egyes csomaghoz beírni). Esetleg egy (csomag-függő) CONF_ARGS változóban tárolod a ./configure opcióit (ebben az esetben --enable-charset - a prefix opciót meg mindig hozzáírod).

Tehát pl. 


#!/bin/sh
# main.sh

PREFIX="/usr"
pkg_download_source() {
  curl --megfelelő-paraméterek ${PKG_SOURCE}
}

pkg_extract() {
  tar xf ${PKG_SOURCE}
}

pkg_conf() {
  ./configure --prefix=${PREFIX} ${CONF_ARGS}
}

pkg_build() {
  make
}

pkg_install() {
  make install DESTDIR=${DESTDIR}
}


#!/bin/sh
# pkgbuild.sh
PKG_PATH=/usr/pkgfiles

# Behúzzuk a main.sh fájlt, ami az alapfüggvényeket tartalmazza
source main.sh
# Behúzzuk az előállítandó csomag conf-fájlját, ami a csomag-specifikus infókat tartalmazza
source ${PKG_PATH}/${1}.conf

pkg_download_source
pkg_extract
pkg_conf
pkg_build
pkg_install


# /usr/pkgfiles/mc.conf
PKG_VERSION=4.8.15
PKG_SOURCE=http://ftp.midnight-commander.org/mc-${PKG_VERSION}.tar.xz
CONF_ARGS=--enable-charset

Tehát ha pl. az mc-t akarod előállítani, akkor pkgbuild.sh mc. Ha a verziója változik, akkor csak a PKG_VERSION=... sort kell átírni. Ha nem csak mc-t akarsz használni, akkor bármelyik más csomaghoz kb. annyit kell írnod, mint az utolsó fájlban: 


# /usr/pkgfiles/foo.conf
PKG_VERSION=1.2.3
PKG_SOURCE=http://foo.com/foo-${PKG_VERSION}.tar.bz2
CONF_ARGS="--enable-bar --disable-foo"

Persze lehet ezeket finomítani, hibaellenőrzéssel bővíteni, vizsgálni, hogy van-e egyáltalán ./configure, függőségeket hozzáadni (pl. PKG_DEPENDS="foo bar"), csomagleírást, stb.

Úgy töntöttem, a legegyszerübb ha van egy külön sript ami lekéri a legfrissebb verzió, útána belerakja a pkversion nevű file-ba. Így nézz ki a script:

#!/bash/bin

function ProgressBar {
let _progress=(${1}*100/${2}*100)/100
let _done=(${_progress}*4)/10
let _left=40-$_done
_fill=$(printf "%${_done}s")
_empty=$(printf "%${_left}s")
printf "\rCsomag frissítés : [${_fill// /#}${_empty// /-}] ${_progress}%%"
}

numberofqueries=3
queriesdone=0

function ProgressNext {
let queriesdone=queriesdone+1
ProgressBar $queriesdone $numberofqueries
}

save="$HOME/.bashpkg/pkgversions"

version="$(curl -L -s http://ftp.midnight-commander.org/ | sed -rn '/href="mc/ s@.*a href="(mc-[^"]*.tar.gz).*@\1@p' | sort -V | tail -n 1)"
echo "$version" >> "$save"
ProgressNext
version="$(curl -L -s http://ftp.gnu.org/gnu/nano/ | sed -rn '/href="nano/ s@.*a href="(nano-[^"]*.tar.gz).*@\1@p' | sort -V | tail -n 1)"
echo "$version" >> "$save"
ProgressNext
version="$(curl -L -s http://ftp.gnu.org/gnu/make/ | sed -rn '/href="make/ s@.*a href="(make-[^"]*.tar.gz).*@\1@p' | sort -V | tail -n 1)"
echo "$version" >> "$save"
ProgressNext

A letöltéshez, nincs más dolgom mint kiolvasni a pkversion-ból a filt. Valami ilyesmiképp gondoltam:

Download() {
for m in $(sed -rn '/mirror/ s/(\mirror=|\")//pg' $CONFIGS64/$PACKNAME.cfg); do
for v in $(sed -n '/$PACKNAME/p' $HOME/.bashpkg/pkgversions); do
cd $SOURCES
wget $m/$v
done
done
}

A "don't repeat yourself" elv azért nem annyira lenne hülyeség. Nézd meg az mc, nano, make verzióit lekérdező egysorosakat: gyakorlatilag mindegyik ugyanaz, csak a curl-nek átadott cím más (talán lehetne egy változóban tárolni az értékét?), a sed feltételében szereplő regexp annyiban különbözik, hogy..., illetve a cserében mc-, nano, make- van. A többi karakter pedig tök ugyanaz. Ha lesz száz csomagod, akkor százszor fogod leírni ugyanazt?

Az "ahogy én csinálnám"-rész következik.

A függvény, ami lekérdi a legújabb verziót: 


# $1 - csomag neve
get_latest_version() {
  source /usr/pkg/$1.conf
  SUFFIX=${SUFFIX-.tar.gz}
  curl -L -s ${PKG_DL_URL} | sed -rn "/href=\"${PKGNAME}/ s@.*a href=\"${PKGNAME}-[^\"]*${SUFFIX}).*@\1@p" | sort -V | tail -n 1
}

A konfigfájlok (részei): 


# mc.conf
PKGNAME=mc
PKG_DL_URL=http://ftp.midnight-commander.org/
SUFFIX=.tar.gz

# nano.conf
PKGNAME=nano
PKG_DL_URL=http://ftp.gnu.org/gnu/nano/
# SUFFIX=.tar.gz # nem adjuk meg, jó az alapértelmezett

#make.conf
PKGNAME=make
PKG_DL_URL=http://ftp.gnu.org/gnu/make/
# itt már ide se írom a SUFFIX-ot

És ezután a get_latest_version mc kiírja legújabb mc-verziót, a get_latest_version nano a legújabb nano-verziót, stb. Felesleges fájlba írni (aminél aztán a régi bejegyzést törölni kell, stb.).

Ja, csak hookolhatova kell tenni, mert van, amikor nem ${PN}-${PV}.tar.gz formatumban vannak a fajlnevek, hanem ${PN}-linux-amd64-v${PV}-rev0ab2cde6f.tar.gz formatumban. Itt szerintem a DRY elv annyibol hulyeseg, hogy nem egyszerusitesz tul sokat, a hookolhatosag tobb boilerplate-t kivan, mint a mindig masolgatott script. Persze, parameterezhetove lehet tenni azt a scriptet, de ha meg masra van szukseg, az jobb lenne, ha egybol meg lehetne adni.
--
Blog | @hron84
Üzemeltető macik

Itt szerintem a DRY elv annyibol hulyeseg, hogy nem egyszerusitesz tul sokat, a hookolhatosag tobb boilerplate-t kivan, mint a mindig masolgatott script. Persze, parameterezhetove lehet tenni azt a scriptet, de ha meg masra van szukseg, az jobb lenne, ha egybol meg lehetne adni.

Ez csak az én hozzászólásomra reakció/kritika.

Tetszik a megközelítés. Van valahol egy kis hiba amit még nem sikerült kijavítanom. Ezt írja ha futtatom.

sh bashpkg --install mc
sed: -e expression #1, char 46: Unmatched ) or \)

Szerk: Közben rájöttem mi volt a gond és javítottam. De a lenne egy olyan kérdésem, hogy a letöltéshez hogyan adom hozzá a fügvényt?

Megadtad a fügvényt, hogyan lehet lekérni a verziót. Eddig rendben is van. Viszont a csomagot le kell tölteni. Azt tudom, hogy a forrás url-t már nem kell kiolvasni külön a konfig file-ból. A "PKG_DL_URL" megcsinálja.
wget ${PKG_DL_URL} eddig rendben van de ha utána írom a get_latest_version-t akkor már nem müködik.

Ja, értem. Először a get_latest_version-nal feltöltöd a PKG_VERSION-t (mondjuk PKG_VERSION=`get_latest_version $PKG_NAME`), és utána hívod meg a wget-et.

Persze egy-két buktató van:
1. Ha automatikus a verzió-meghatározás, akkor a conf-fájlokban ne legyen a PKG_VERSION-nak érték adva (hiszen felülírja azt, amit a get_latest_version-nal adsz). Persze ezen is lehet finomítani (pl. ha a get_latest_version hibára fut, akkor alapértelmezetten a verzió legyen 1.2.3).
2. A conf fájl beillesztése a verzió meghatározása után kell, hogy történjen, mivel source-kor a PKG_SOURCE értéke "meghatározódik", az aktuális PKG_VERSION értékkel. Viszont ha nem illeszted be a conf fájlt, akkor honnan tudod, hogy milyen URL-t kell lekérni? :) Persze erre is van egy (több) megoldás, pl. saját magad rakod össze a get_latest_version hívása után a PKG_SOURCE-ot.

pkg_version='get_latest_version $PACKNAME' sajnos, a szöveget helyetesíti be ne az eredményt.

wget ${PKG_DL_URL}$pkg_version

pusztito ~/Csomagkezel��/multilib_1.6 $ sh bashpkg --install mc
--2015-12-24 14:25:46-- http://ftp.midnight-commander.org/get_latest_version
Resolving ftp.midnight-commander.org... 64.50.233.100, 64.50.236.52
Connecting to ftp.midnight-commander.org|64.50.233.100|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-12-24 14:25:46 ERROR 404: Not Found.

Ez az index oldalt parsolunk dolog nekem nagyon szaglik. Oke, hogy az mc-nel, meg mondjuk tovabbi 200 alkalmazasnal mukodik, de pl. ha valamit S3/CloudFront-on keresztul szolgalnak ki, annak eleve nem HTML a directory indexe (ha van neki), hanem XML, de rosszabb esetben nincs is neki indexe egyaltalan. Siman lehet olyan, hogy az a mappa, ahol a fajlok vannak, egy 404.

Nem akarlak bantani, de talan nem veletlen az, hogy a csomagkezelo keszitok tobbsege statikus verzioszamokat hasznal, hanem oka van neki, megpedig az, hogy ezek a verziok tutira le vannak tesztelve, nem bugosak, es egyutt tudnak mukodni a rendszer mas reszeivel. Az, hogy kijott egy uj verzio, az legyen neked, mint maintainernek notifikacio, de erre alapozni egy csomagezelo mukodeset - az igazabol a "vagy nagyon bator, vagy nagyon ostoba" kategoriaja, es nem tudok donteni.

Arrol nem beszelve,hogy ha megvaltozik az oldal szerkezete, pl. mostantol nem href-ben lesznek kinn a linkek, hanem JS-bol tolti fel, akkor mit csinalsz? Unsupported lesz a csomag?

Annyi buktato van ebben, hogy logikusan vegiggondolva, en sose biznam meg a sajat rendszeremet se egy ilyen lehetosegre. Mondom, a notifikacio meg okes, de hogy ez alapjan az info alapjan update-ljen a cucc... az nonszensz.
--
Blog | @hron84
Üzemeltető macik

Tehát magát a curl -L -s ... parancsot akarod? Nem lenne egyszerűbb, ha a ver változó pont ezt a parancsot tárolná? Azaz ver="curl -L -s ...".

De ha egy tanácsot elfogadsz: hagyd ezeket a mágikus sorokat minden egyes "csomag" esetén. Legyen egy központi "verzió-meghatározó" függvényed, ami pl. egy ftp-lista fájljait sorbarendezi verzió szerint és a legfrissebbet adja vissza.

( PP v | 2015. 12. 22., k – 16:30 )

Sziasztok. Csomag készítésnél szerintetek melyik a jobb változat. A make DESTDIR vagy a prefix megadása. Én a prefix megadás melett gondolkodom, ahogy az lfs építésnél.

Ahogy én látom, többféle megoldás van. Mindenki máskép közeliti meg a problémát és hozzá a megoldást. Szerintem, ebböl lehet igazán tanulni. Rádásul, nem csak a csomagkezelők felépítéséről, hanem programozásról(script írás)-ról is bővitheti az ismereteit minden kezdő és haladók. Már többször leírtam, hogy nem olyan csomagkezelő a cél ami jobb a mostaniaknál. Nem is lesz publikálva. Inkább a cél, hogy némileg elsajátitsam a programozás logikáját. Elismerem, elég göröngyös utat választottam ehez.

Eredetileg, mikor indítottam az a topikot, akkor egy egyszerű csomagkezelő volt a cél. Most is ez a cél, csak más megközelítésbe és némi finomhangolással. Kicsit többmindenre szeretném felkészíteni a mostani verziót. Meg persze multilib-re is.

+sok.

Es meg azt is hozza kell tenni, hogy minden megoldast tobbszor at kell gondolni, alaposan, meg kell vitatni masokkal, akik nalad jobban ertenek hozza, es a legjobbat, a legtisztabbat beepiteni a napi rutinba. Nekem sajnos nagyon sok rossz beidegzodesem van, mert a legelejen meg teljesen onalloan, egyedul kezdtem el tanulni a programozast, es minden teren lenne hova fejlodnom, csakhat ha mar valami meggyokeresedett, azt nehez kiirtani.
--
Blog | @hron84
Üzemeltető macik

Nincs igazad. Tanulni, ugy istenigazabol tanulni valodi, eletszagu peldakbol lehet. Ezert javasoltuk tobbszor, hogy olvasd at meglevo csomagkezelok forrasat, tanulmanyozd, probald meg eloszor azt megerteni, hogy azok hogyan epulnek fel. Azokat a programokat olyan emberek irtak, akik mar egyszer (sokszor!) vegigmentek azon az uton, amin most te elindultal. Nem kell kovetned oket mindenben, de ahhoz, hogy tanulj, az elso lepes a megertes.

Van az a kozmondas, hogy az okos ember a mas karan tanul, a hulye meg a sajatjan. Te a masodik utat valasztottad, annak ellenere, hogy majdnem egyhanguan a fel HUP azt javasolta, hogy az elson menj. Ezek utan nemcsak elvarod, hogy tapsoljunk a valasztasodhoz, de azt is, hogy ha belecsapodsz azokba a falakba, amikrol mi tudtuk (vagy legalabbis sejtettuk), hogy bele fogsz csapodni, vakarjunk ki, es lokjunk tovabb. Felre ne erts, nem akarlak bantani, azt csinalsz amit akarsz, ez egy (kind of) szabad orszag. De ha ugy kersz segitseget, hogy utana nem fogadod meg a tanacsot, amit kapsz, akkor ne csodalkozz, ha az emberek egyre kevesbe szivesen segitenek egy olyan uton, amirol tudjak, hogy nem a legjobb.

Hidd el, ~10 ev uzemeltetesi (es Bash-fejlesztesi) tapasztalattal a hatam mogott nem a levegobe beszelek. En vegigjartam azokat a staciokat, amiket most te jarsz vegig, es egyaltalan nem vicces az az ut.
--
Blog | @hron84
Üzemeltető macik

Kicsit elvesztettem kinek is szól az utolsó hozzászolások. Ha nekem, akkor szoktam nézegetni csomagkezelőket. Többek között, aur és portage-t. Nem arról van szó, hogy nem fogadom meg a tanácsot. Most is a ti tanácsotok szerint készítgetem a csomagkezelőt. Mindössze, ha eszembejut valami más megközelítés, kikérem a véleményeteket. Tudom, számotokra az én megközelitéseim nem a legjobbak. Sőt! Az embereknek megvan az a rossz tulajdosága, akaratlanul is de a saját káran tanulja meg a leckét.

Soha nem tanultam iskolába programozást. Tulajdonkép a bash scritet is csak a logika elsajátitása miatt választottam. A csomagkezelő(szerüség) csak a tanulást szolgalja.

Igen, csak ez nem egy tipikus tanulo projekt, mert kozben a sajat rendszeredet meg - ha jol ertem - ezzel manageled.

Illetve, a problemam nem is feltetlen azzal van, hogy ez egy tanulo projekt, hanem hogy ebbe ugy vagtal bele, hogy egy csomo mindent nem gondoltal at, hogy annak hogyan is kellene mukodnie. Az ember nem ugy ul le forrasfat olvasni, mint egy sci-fi regenyt, hogy na akkor ezt most jol kiolvasom, hanem ugy, hogy celzottan keres dolgokra megoldast. Csomagkezelo irasaba emberek tobb evnyi uzemeltetesi es fejlesztoi tapasztalattal a hatuk mogott se nagyon mernek belekezdeni, mert nagyon sokretu, sokkomponensu problema, az egesznek baromira rugalmasnak es adaptivnak kell lennie, raadasul ket, egymastol kicsit tavol allo teruleten is profinak kell lenned (uzemeltetokent es fejlesztokent is jonak kell lenned ehhez). Kezdve attol, hogy nem minden projektnek van letoltes-listazo oldala, egeszen addig, hogy neha meg a letoltes maga is igen trukkos tud lenni (lasd pl. az Oracle JDK koruli hackokat a megfelelo AUR csomagban). Es ez meg csak a letoltes, a megszamolhatatlan mennyisegu (es minosegu) build rendszert fel sem emlitem, oke, hogy a projektek 80%-a az autotools-cmake parost hasznalja, de egyreszt az autotools-t nagyon sokszor rosszul hasznaljak, rosszul konfiguraljak (tehat nem jelent konstans minoseget a hasznalata), masfelol pedig a maradek 20-30% pedig total egyedi build rendszert hasznal, amiket eleve 2-3 nap kiismerni, es az egyik legtipikusabb hiba, hogy egyaltalan nem ismerik a DESTDIR-t, vagy ha ismerik is, nem hasznaljak konzisztensen. Eleg csak megnezni a Gentoo altal a projektekhez csomagolt patchek mennyiseget. Es ez mar egy sokkal jobb vilag, mert a forrasalapu disztrok miatt sok fejleszto vette a faradsagot, es atnezte es alkalmazta azokat a patcheket, amiket a Gentoo-hoz hasonlo projektek fejlesztoi bekuldtek. Ot-het evvel ezelott sokkal siralmasabb volt a helyzet.

Nekem tudod mi volt az elso harom tanuloprojektem? Az elso egy szamologep alkalmazas volt VB6-ban (igen, egy idoben kacerkodtam a desktop fejlesztessel), a masodik egy forummotor volt, a harmadik egy blogmotor. Ezek tanuloprojektek, mert egyszeru, konnyen atlathato szerkezetuk van, jol ismert es jol definialhato problemakkal szembesulunk, es elore lathato hibakba szaladunk bele. Egy csomagkezelo fejlesztoje azonban sokszor olyan problemakkal szembesul, amikkel elotte senki mas, olyan megoldasokat kell nullarol feltalalnia, amikhez kell az a sok eves tapasztalat, ami neked nincs meg.

Felre ne ertsd, en orulok, hogy egy ilyen projektbe vagtad a fejszedet, de amig nem erted meg, hogy ez nem a legjobb utja-modja egyaltalan a fejlesztesi metodologiak elsajatitasanak (foleg a bash nem igazan jo erre), addig nagyon nehez utad lesz, es nem mindig fogunk tudni segiteni. Folyamatosan azt latom, hogy amikor kerdessel fordulsz felenk, akkor nem is feltetlen az a baj, hogy nem tudod megoldani a problemat, hanem meg a kerdest sem erted, az ajanlott megoldast meg kevesbe. Ez abbol fakad, hogy ehhez a mufajhoz _kell_ a tapasztalat, muszaj, hogy lassal tobbszaz projektet forrasbol fordulni, lasd es ertsd, hogy a meglevo csomagkezelok mit miert csinalnak, tudjal kerdeseket megfogalmazni az egesz mukodesevel kapcsolatban.

Keress olyan projekteket, olyan programnyelveket, amik egyszerubbek, jobban attekinthetoek, tanuld meg a fejlesztest alaposan, menj el ket-harom evre Gentoo-t uzemeltetni, utana gyere vissza, es talalj fel egy uj csomagkezelot, ami lehet, hogy meg sikeres is lesz.
--
Blog | @hron84
Üzemeltető macik

Neked, aki szemlátomást a közel semmit is sokkal jobban tudod azoknál, akik nem sajnálják az értékes idejüket arra, hogy segíteni próbáljanak rajtad. Nem az a baj, hogy nem tudod - senki sem tud mindent helyből. és később sem. A baj az, hogy abszolút időpocséklásnak tűnik reagálni rád, mert figyelmen kívül hagyod úgy a tanácsok, mint az érvek többségét! Szerintem: ne beszélj mellé, ne magyarázz, hanem vagy fogadd meg a tanácsot, ha kérsz és kapsz, vagy ne kérj! Ezen felül figyelj oda jobban arra, hogy hogyan írsz, illetve szükség esetén vegyél igénybe egy Neked szimpatikus helyesírás-ellenőrzőt, mert eleve meghatározza a hozzám hasonlóan klasszikus antipedagógusok hozzáállását és így a reakció várható hangvételét az az elmeállapot, amibe a szösszeneteid végigrágása juttat... Sorry, de ez van.
------------------------
{0} ok boto
boto ?

@PP Egy kis kiegeszites/finomitas a fentihez: nem a tokeletes helyesiras az elvaras, hanem a hozzaszolas elkuldes elotti atolvasasa, akar tobbszor is. Ha rossz a billentyuzeted, akkor kulonosen fontos ez, mert nagyon sokszor ertelemzavaro betu- rag- es szohianyok vannak a hozzaszolasaidban. En is ekezet nelkul irok, de probalok mindig teljes szavakat, helyesen irni ettol fuggetlenul, hogy ertheto maradjon, hogy mit irok. Ha kell, meg elkuldes utan is ketszer elolvasom es javitom a hozzaszolasomat (erre a kis "szerkesztes" link valo a komment jobb also sarkaban)
--
Blog | @hron84
Üzemeltető macik

( PP v | 2016. 01. 16., szo – 07:32 )

Sziasztok !

A rendszer frissítés adott egy új ötletet. Egy virtuális meghajtóra vagy valami hasonlóra forgatnám le a csomagot és onnét kerülne be az éles rendszerre. Sajnos, nem nagyon ismerek ilyen programot vagy megoldás. Egy jónak tűnő megoldást találtam, név szerint a "rootfs". Mielőtt mélyebben belevágok a tervezgetésbe, gondoltam kikérem a ti véleményeteket. A rootfs megfelelne a feladatnak vagy van valami jobb is? Esetleg mire kéne különösen figyelnem?