[Udsl-group] Saludos - Fun fun fun!!!

[Luis F. Araujo]

Saludos gente,

Ok, luego de un domingo por la noche sin nada mejor que hacer,
porque no comenzar a probar ideas del PAL? :-)

Hice un pequeño PP (Package Provider) de prueba en Objective Caml , para
ver que tal
van nuestras ideas, al parecer si son factibles, al menos lo básico funciona
decentemente. Claro, aún le falta MUCHO , pero alli vamos....

El servidor únicamente tiene como datos de entrada (interfaz?):
Tres cadenas de texto [1], en forma consecutiva, representando lo siguiente:
cadena1) Nombre del paquete
cadena2) URL del paquete
cadena3) Tipo del paquete ("0" para fuentes, "1" para binario)

Ya con estos _parámetros_ del servidor (hey si!, se puede ver el
servidor como
una funcion!!) solo se tendria que escribir el cliente enviandole la
respectiva data.

Los tipos de sockets que usaremos son los SOCK_STREAM y  el tipo de
direccion de sockets ADDR_INET.

Ok, teniendo algo con que jugar, experimentar, pues surgen nuevas
necesidas, ideas y problemas evidentemente :-) , aquí expóngo algunas:

1) Las responsabilidades del PP debieran de ser las siguientes:
recibir la data, descargar el paquete y dependiendo de este colocarlo en
el /var/pkg/src , /var/pkg/bin [2]. Luego pasar control (dependiendo del
paquete)
al SPB o BPB, estos a su vez retornaran el control al PP al terminar la
operación
y es el PP quién notificará el status a las capas correspondientes.
(Check: el SPB y el BPB solo pueden ser accedidos por el PP).
Aparte de eso el PP debe correr como daemon como ya todos acordamos.

2) El SPB [3] por como lo tengo planeado justo ahora, _solo_ tomará un
argumento,
el nombre del paquete  (si, exacto la primera cadena de caracteres),
y debe hacer en mi opinión lo siguiente:
- Determinar la relación entre el nombre del paquete y el script de
paquete.
Las pruebas que estoy haciendo las tengo funcionando con un archivo, en este
archivo se encuentran los nombres de los paquetes asociados a su(s)
respectivos
scripts (cada paquete puede tener varios scripts por versiones, en este
punto
tambien pudieramos poner un límite de cuantas versiones un paquete puede
tener).
- Luego el SPB simplemente ejecuta el script (aqui les anexo en este email,
un modelo inicial de como podria ser el script del paquete grep, como
notarán el
nombre del script hace referencia a la versión exacta del
paquete+extension).
- Despues de eso, el SPB se queda fuera del juego, y el control lo toma
el script en si,
ventajas:
a) El script es self-contained, tiene su propio nombre de programa,
nombre del paquete del programa (si, ambos campos pueden ser diferentes),
cambia al directorio respectivo para empezar el proceso de compilación
del paquete;
así que toda esa funcionalidad quedaria encapsulada en el script y no
tendriamos que
_sobre-cargar_ el PAL en ningun layer para intentar de hacerlo _super_
inteligente.
b) Los scripts serian escritos en bash standard, haciendolo muy fácil para
los mantenedores.
c) Seria fácil y eficiente en si... vean el script anexo con este email.
- Luego el script le pasa el control al SPB de nuevo, y es aquí, dónde este
se va a encargar de empaquetar (Algo aún por definir).
- Después de empaquetado, el SPB retorna el control con respectivo
status al PP.
Justo en estos momentos, estoy probando el SPB en bash, puros
ugly-hacks, solo
para probar, pero Jose me comento de hacerlo en Ruby, alguien se ofrece?

3) El BPB.. bien.. de este podemos preocuparnos(y si lo hacemos bien con el
SPB, puede que ni nos preocupemos) luego, pero en lineas general el
comportamiento
sería algo similar.

4) Los formatos de los paquetes. Es decir, que obtenemos del SPB?!?!
Estaba pensando en algo asi: Un directorio conteniendo a su vez un
directorio raíz imaginario y metadata necesaria, ejemplo, para el
paquete grep,
podriamos obetener la siguiente jerarquía:
pal-grep/digest   // md5sum
pal-grep/....        // otra metadata
pal-grep/img_root
pal-grep/img_root/bin/grep
pal-grep/img_root/bin/fgrep
pal-grep/img_root/bin/egrep

Así el instalador sólo tiene que descomprimir el img_root al / para
instalar los paquetes.

5) Por último punto (sólo de este email :-) , respecto al script de los
paquetes,
debieramos de elaborar una standard library para los shell scripts.
Algún voluntario?

6) Este si es el último :-) , alguien tiene un nombre ya a esto, si nadie
aparece con nada para  esta semana, pues le colocare cualquier cosa,
antes de que siga amontonando archivos con "pkg". [4]

Ok, ahora si, eso es todo.
Seria bueno , como les comente (Jose y Javier), que hicieran
un pequeño cliente en C++ que se comunique con el PP, y así probar
su independencia y funcionalidad.

Por los momentos espero agregarle el soporte daemon al PP, y corregirles
algunos core-dumps de 1TB :-), y luego lo envio al CVS,
tambien creo que haré algo pequeño para la libreria
de los scripts, y seguir estropeando el SPB :-).

Bueno, con este email creo que ya cada uno puede empezar a lanzar
sus piedras :-)

Saludos y happy coding.

[1] Aqui una cadena de texto es una linea de caracteres terminando
en nueva linea. Como le comentaba a Jose, debiera de funcionar
tambien enviando una cadena completa pero delimitando cada campo
con nueva linea.. wait.. no es lo mismo? :-)

[2] Nombres y paths aún por definir.

[3] Comenzamos primero con el SPB para luego ir más fácil con el
BPB.

[4] Nombre del manejador y nombre de extension de los paquetes al menos.

-- 

                        -- luis

NAMESRCPKG="grep-2.5.1a.tar.gz"
DIRNAME="grep-2.5.1a"

echo -e "\nInstalling " $0

echo -n "Proceding in .."
for i in 1 2 3 4 5 ; do
        sleep 1
        echo -n "$i "
done

echo -e "\n\nUntaring and uncompressing package\n"
sleep 2
tar zxvf $NAMESRCPKG

cd $DIRNAME

echo -e "\n\nConfiguring package now...\n" 
sleep 2
./configure

echo -e "\n\nCompiling package now...\n"
sleep 2
make