# Cosa dovrebbe cambiare in portage?

## shogun_panda

Ciao ragazzi...

Lurkando un po' ho trovato questo progetto riguardo cambiamenti importanti a portage...

Credo che in molti siamo d'accordo riguardo la necessita' di riscrivere il sistema portante di gentoo, almeno per quanto riguarda l'introduzione di un database cosicche' le ricerche, installazioni ed altro saranno velocizzate alla maniera di eix...

Il dubbio che mi ponevo io e': Bisogna proprio usare il C, e in generale scegliere un linguaggio di programmazione?

Il ragionamento che ho fatto e' questo...

E' ovvio che la struttura degli ebuild non cambiera' di molto...Forse di niente, a parte forse voler usare l'XML per rendere piu' facile agli utenti la scrittura degli ebuild. Ma aldila' di quello, il grosso del riscrivere portage e' il fargli usare un database centralizzato (chiaramente non client/server)...

Quindi tutti pensano a SQLite...

E fino a qui sono d'accordo...

Ma il linguaggio di programmazione?

Aldila' che *SECONDO ME* il linguaggio usato non incide molto sull'esecuzione delle operazioni, (almeno non con i PC di oggi), non sarebbe meglio, a vostro avviso, semplicemente designare la struttura del database (e ovviamente dei dati interni), e la collocazione nelle directory e pubblicare tutto sotto forma di specifiche affinche' ognuno possa scegliere il linguaggio da usare?

Questa mia considerazione deriva dal fatto che la "Gentoo e' scelta"...Ora, se uso gentoo e' ovvio che debba usare il sistema portage...Ma chi mi obbliga a farlo da shell? Perche' non affiancarci anche un tool grafico? Chiaramente un tool che vada a operare direttamente sul database, non chiamando emerge (come succede oggi)...

Tutto questo mi e' venuto in mente quando ho avuto la pensata di scrivere un progetto simile a portage-c, ma usando (per favore, NON replicate) Mono/C#...Ripensadoci ho poi concluso che molti avrebbero avuto da ridire sulla mia scelta...Allora ho pensato che l'ideale e' che il sistema fosse staccato da qualunque linguaggio di programmazione

Finito sto sproloquio scritto e formattato in maniera barbara, aspetto le vostre repliche...

PS: In ultimo...L'aggiunta del database chiaramente faciliterebbe l'introduzione di varie feature...Secondo voi, da 1 a 10, quanto sarebbero utili le dipendenze inverse?

----------

## _sys/sid

Non so'... Io preferisco linguaggi piu' a basso livello come il C... pero' sicuramente come hai detto tu con i pc di oggi il linguaggio non influisce molto sulle prestazioni dell'applicazione... Ma sicuramente il linguaggio modifichera' i tempi di sviluppo...

Python per me' si presta molto bene ad essere modificato e testato piu' facilmente rispetto a C quindi io, se dovessi riscrivere portage, lo riscriverei sempre in python pero' aggiungendo un supporto database per velocizzare le ricerche...  :Confused: 

----------

## fedeliallalinea

 *shogun_panda wrote:*   

> Credo che in molti siamo d'accordo riguardo la necessita' di riscrivere il sistema portante di gentoo, almeno per quanto riguarda l'introduzione di un database cosicche' le ricerche, installazioni ed altro saranno velocizzate alla maniera di eix...

 

Questo non lo trovo assolutamente necessario anzi.... e' un assoluto spreco di risore imho. Perche' non migliorare semplicemente quello gia' esistente? E poi dov'e' il problema ad usare eix? Io non vedo nessun giovamento che potrebbe portare un progetto del genere. Chiaramente tutto imho

----------

## shogun_panda

 *fedeliallalinea wrote:*   

>  *shogun_panda wrote:*   Credo che in molti siamo d'accordo riguardo la necessita' di riscrivere il sistema portante di gentoo, almeno per quanto riguarda l'introduzione di un database cosicche' le ricerche, installazioni ed altro saranno velocizzate alla maniera di eix... 
> 
> Questo non lo trovo assolutamente necessario anzi.... e' un assoluto spreco di risore imho. Perche' non migliorare semplicemente quello gia' esistente? E poi dov'e' il problema ad usare eix? Io non vedo nessun giovamento che potrebbe portare un progetto del genere. Chiaramente tutto imho

 

Aspetta, preciso una cosa...

Non e' che per me e' importante riscrivere portage perche' così cerco le cose piu' veloce invece di usare eix...

E' una cosa marginale...Perche' emerge effettua una ricerca anche quando installa, aggiorna rimuove e controlla le dipendenze di un pacchetto...

E li' non puoi usare altri programmi...Fino a che si useranno semplici file di testo per le informazioni, ci mettera' sempre troppo tempo, anche usando Reiser4 e amenita' simili...

Il database e' utile anche per questo...In piu', trattandosi di un file (o piu' file) come fa SQLite, si ridurrebbe, e di molto anche, lo spazio e gli accessi al disco fisso...

Per quanto riguarda l'intervento di sid, diciamo che siamo totalmente d'accordo (del resto sono indeciso tra Mono+GTK# o Python+PyGTK  :Very Happy: )...

----------

## fedeliallalinea

 *shogun_panda wrote:*   

> E' una cosa marginale...Perche' emerge effettua una ricerca anche quando installa, aggiorna rimuove e controlla le dipendenze di un pacchetto...

 

Ma io oltre il tempo di ricerca non vedo dove sia il problema per il resto. Sono tutte operazioni che non mi bloccano il lavoro (nel senso che quando aggiorno lancio il comando e lascio andare

 *shogun_panda wrote:*   

> E li' non puoi usare altri programmi...Fino a che si useranno semplici file di testo per le informazioni, ci mettera' sempre troppo tempo, anche usando Reiser4 e amenita' simili...

 

Per lo spazio non saprei visto che comunque i dati vengono salvati quindi di spazio ne verra' occupato

----------

## Sasdo

Uhm... secondo me sarebbe errato richiedere un database separato solo per gestire il portage....

...e sono contrario all'affermazione: "con i computer di oggi non si nota la differenza"... secondo me la si nota eccome la differenza... credo che un portage riscritto in C sia molto più veloce di quello attuale (credo... non ho provato!).

Se proprio io farei una cosa tipo:

database tipo eix ed implementazione in C.

Si uniscono i vantaggi di un database che non richiede dipendenze particolari e la velocità di un codice C..

...nella speranza di non aver sparato vaccate....

il Sasdo

----------

## Cazzantonio

Imho i problemi che ha tuttora portage (e sono gravi) dovrebbero essere risolti prima di cercare soluzioni del tipo "riscriviamo tutto"

portage funziona abbastanza bene... quello che gli manca sono delle feature, a mio giudizio essenziali, che troppo spesso vengono fornite da tool esterni piuttosto che essere integrate di default

Mi riferisco ovviamente ad unclepine che riassume una serie di feature essenziali senza le quali probabilmente sarei già passato ad un'altra distribuzione  :Wink: 

Comnque oltre a unclepine ci sono un sacco di tool esterni che risultano utli, se non fondamentali, e non capisco perché gli sviluppatori di portage non si decidano a inegrarli nei gentoolkits

Mi sembra che portage sia stato sviluppato egregiamente fino ad una fase beta... poi tutti gli sviluppatori sono andati in vacanza  :Shocked: 

Non nutro una grande opinione del lavoro attuale degli sviluppatori di portage (l'unica innovazione che ho visto recentemente sono stati i cascading profiles... che tutto sommato non è che fossero in cima alla lista delle mie priorità)

C'è un'altro problema di portage di cui ultimamente mi sono reso conto... l'uscita dei pacchetti da portage  :Rolling Eyes: 

Il fatto è che se uno usa una versione vecchia di un determinato pacchetto (e ne ha tutti i diritti... gentoo non dovrebbe essere "all about choiches"?) rischia di vederselo eliminato da portage al prossimo emerge sync...

Questo problema potrebbe essere evitato in modi molto semplici di cui almeno uno mi viene in mente or ora...

Uno warning surante l'emerge sync del tipo:

"Attenzione! I seguenti pacchetti non sono più nel portage ufficiale! 

(segue la lista dei paccehtti con le loro versioni, magari vengono segnati anche quelli che sono correntemente installati)

Tali pacchetti verranno spostati in /usr/local/portage

Se non ti servono eliminali da tale directory"

Mi sembrerebbe un accorgimento minimo e trovo veramente fastidioso il fatto che i developer di portage non ci abbiano ancora pensato...  :Evil or Very Mad: 

----------

## GhePeU

 *Cazzantonio wrote:*   

> Uno warning surante l'emerge sync del tipo:
> 
> "Attenzione! I seguenti pacchetti non sono più nel portage ufficiale! 
> 
> (segue la lista dei paccehtti con le loro versioni, magari vengono segnati anche quelli che sono correntemente installati)
> ...

 

sai che palle dover andare ogni volta a eliminare pacchetti?

c'è il portage overlay: se mi serve una particolare versione di un pacchetto me la copio lì e sono a posto per sempre

----------

## fedeliallalinea

 *Cazzantonio wrote:*   

> Comnque oltre a unclepine ci sono un sacco di tool esterni che risultano utli, se non fondamentali, e non capisco perché gli sviluppatori di portage non si decidano a inegrarli nei gentoolkits

 

Il perche' e' molto semplice, ognuno di questi tool usa delle funzioni che vengono riscritte ogni volta e probabilmente basate sull'output di emerge, e se l'output di emerge viene cambiato? Se unclepine sarebbe stato scritto utilizzando le librerie presenti in /usr/lib/portage/pym probabilmente non solo sarebbe stato messo in gentoolkit ma addiritura integrato in portage (forse). Non e' una critica a unclepine che uso regolarmente.

 *Cazzantonio wrote:*   

> Mi sembra che portage sia stato sviluppato egregiamente fino ad una fase beta... poi tutti gli sviluppatori sono andati in vacanza  

 

E' sempre la stessa cosa, noi abbaimo fatto qualcosa per portare avanti portage, io personalmente no e quindi non mi sento di criticare gli altri che mettono a disposizione il loro tempo libero.

----------

## Cazzantonio

 *fedeliallalinea wrote:*   

> Il perche' e' molto semplice, ognuno di questi tool usa delle funzioni che vengono riscritte ogni volta e probabilmente basate sull'output di emerge, e se l'output di emerge viene cambiato? 

 

Per questo motivo mi piacerebbe che a svilupparlo fossero i developer di portage e non dei volenterosi...

 *fedeliallalinea wrote:*   

> E' sempre la stessa cosa, noi abbaimo fatto qualcosa per portare avanti portage, io personalmente no e quindi non mi sento di criticare gli altri che mettono a disposizione il loro tempo libero.

 

Questa è la tua opinione e la rispetto... la mia opinione è un tantino diversa:

Penso che se ti pagano per fare un lavoro e non lo fai posso rivalermi su di te tramite vie legali, proteste ufficiali, il tuo datore di lavoro e via dicendo...  :Twisted Evil: 

Se tiri su un progetto opensource lo fai per renderlo disponibile alla comunità, e quindi ti prendi anche delle responsabilità e accetti che il tuo operato possa essere giudicato. Proprio perché nessuno li paga e non hanno firmato un contratto non posso rivalermi su di loro se il prodotto non funziona secondo le mie aspettative... percò criticare e protestare mi sembra sacrosanto! :Smile: 

Se uno non protestasse e non criticasse niente significa che non ci sono margini di miglioramento (oppure che non me ne sbatte niente)... secondo me i margini ci sono e il mio impegno (visto che non ho ne' le competenze ne, diciamolo, la voglia di lavorare attivamente sul codice per migliorarlo) sta proprio nel far notare i difetti nella speranza che qualcuno li migliori  :Wink: 

Poi ovviamente cisascuno si comporta come preferisce nel rispetto delle opinioni altrui  :Smile: 

E' che l'idea che nessuno possa giudicare niente e ci si debba accontentare di quello che passa il convento mi sembra disfattista...  :Confused: 

Se fai un lavoro è anche un dovere criticarlo per far risaltare gli eventuali problemi... l'opensource progredisce anche così!  :Smile: 

@GhePeU

Capisco che sarebbe una rottura... diciamo che mi piacerebbe poter avere un'opzione da attivare che me lo consenta... chi non gli interessa si tiene il portage aggiornato e via...

Cosa accade se scopro solo dopo che il pacchetto aggiornato non mi funziona come il vecchio? ovviamente tale feature non serve per il desktop di casa... magari per un utilizzo un po' più professionale forse...  :Rolling Eyes: 

Per eliminare gli ebuild in overlay non necessari comunque basterebbe uno script di poche righe....  :Wink: 

Senza contare una cosa fondamentale (ok, è poco probabile... ma di principio non è escludibile):

Cosa succede se improvvisamente l'intera categoria (tutte le versioni) del pacchetto che ti serve viene eliminata da portage  :Question:   :Shocked: 

Che fai? Ok, puoi riscriverti l'ebuild... comunque mi parrebbe logico che prima di eliminarti l'ebuild di un pacchetto che è installato sul tuo sistema portage ti avvertisse  :Rolling Eyes: 

----------

## mrfree

 *shogun_panda wrote:*   

> [...] Secondo voi, da 1 a 10, quanto sarebbero utili le dipendenze inverse?

 

IMHO k, con k >> 11  :Smile: 

Pulizia e ordine sono aspetti fondamentali in una buona distro!

----------

## fedeliallalinea

@Cazzantonio: mi sta bene che quello che dici sulle responsabilita' ma penso che il loro impegno si gia' una responsabilita'. L'unica differenza e', con un progetto opensource, che nessuno ti ha obbligato ad usarlo (o ti ha indotto dicendo che e' il meglio) ne tanto meno hai dovuto sborsare soldi. Chiaramente rispetto anche io la tua opinione. Se tutti pensassimo uguale sai che monotonia  :Very Happy: 

----------

## Sparker

@Cazzantonio Qualcosa del genere viene già fatto: tutti gli ebuild dei pachetti installati sono copiati in /var/db/pkg

Imho il problema della lentezza di portage è 

du -sh --exclude=distfiles /usr/portage

558M    /usr/portage/

per 100.000+ filetti @reiserfs3.6

Con questa mole di dati portage potrebbe essere scritto in assembler e sarebbe comunque lento

(si, lo so che in verità utilizza i metadata, ma sono comunque tanti)

----------

## X-Drum

imho, come ha detto anche qualcuno, prima di una potenziale "ristrutturazione" di portage

adottando magari SQLite, che pur essendo minimale è un db SQL abb veloce (grazie è ridotto all'osso :PPP ),

bisognerebbe appunto introdurre in portage funzioni basilari come:

a-la gestione delle dipendenze inverse (unclepine)

b-metodo di ricerca piu' efficente (eix)

Senza questi due tool esterni ora come ora saremmo in mezzo ad una strada,

in special modo il punto a è di vitale importanza....

Se poi piu' avanti portage adotterà ad un vero e proprio db i vantaggi saranno altri

ma come diceva fedeli, se un sync mi dura due minuti in meno non mi cambia nulla

----------

## btbbass

 *Sparker wrote:*   

> @Cazzantonio Qualcosa del genere viene già fatto: tutti gli ebuild dei pachetti installati sono copiati in /var/db/pkg
> 
> Imho il problema della lentezza di portage è 
> 
> du -sh --exclude=distfiles /usr/portage
> ...

 

cavolo, ma allora con reiser4 la differenza è notevolissima!!!

io ho /usr/portage in una partizione diversa su reiser4 e dando il comando ottengo

```
du -sh --exclude=distfiles /usr/portage

126M    /usr/portage

```

 :Exclamation:   :Exclamation:   :Exclamation: 

----------

## X-Drum

 *btbbass wrote:*   

> 
> 
> cavolo, ma allora con reiser4 la differenza è notevolissima!!!
> 
> io ho /usr/portage in una partizione diversa su reiser4 e dando il comando ottengo
> ...

 

:O impressive!

----------

## .:deadhead:.

domanda: ma se si usasse un db poi il rsync come avverrebbe? IMHO il pregio di portage sta anche nella sua semplicità: solo file di testo, niente db niente catafalchi. 

(at) cazzantonio

Una cosa che si potrebbe fare è chiedere l'istituzione di una repository di tutti i vecchi ebuilds (opera immane), al quale in so di bisogno, ci si affida. Anche se generalmente ebuild storici, vengono mantenuti in portage se il passaggio ad una sucessiva release rappresenta un cambio importante. 

Ma quali sono i pacchetti che ti fanno dannare?

----------

## X-Drum

 *.:deadhead:. wrote:*   

> domanda: ma se si usasse un db poi il rsync come avverrebbe? IMHO il pregio di portage sta anche nella sua semplicità: solo file di testo, niente db niente catafalchi. 

 

alla fine SQLite usa dei files per memorizzare i db,

quindi siamo li trasferisci il/i file/s

----------

## .:deadhead:.

Si ma i singoli ebuilds sono minuscoli files. Se aggiorno una volta ogni settimana tò, quanti ebuild e quanto traffico genero? Quanto sarebbero invece traffico e dimensione totale se l'intero portage fatto a DB? Inoltre, il povero pisquano che volesse imparare a scrivere ebuild, si troverebbe uno strato in più con cui scontrarsi. Riperto , per me la genialità di gentoo rispetto ai sistemi tipo rpm o deb sta anche nella sua semplicità.

Per quanto riguarda l'ipotesi di riscrivere portage in altro linguaggio, portage è in python e la portabilità di sposta dal linguaggio in sè all'interprete python, come per java. rifarlo in C sarebbe altrettanto write once run everywhere (si potrebbe chiedere ai cugini di freebsd)?

E poi, quanto costerebbe i termini di tempo rifare tutto portage e quindi tutti i tools etc etc?

IMHO c'è solo da augurarsi che svolgano bene il loro lavoro i devel e che venga integrata presta presto la funzionalità delle dipendenze inverse.

----------

## neryo

 *btbbass wrote:*   

> 
> 
> cavolo, ma allora con reiser4 la differenza è notevolissima!!!
> 
> 

 

si, se ne era parlato molto nel 3d https://forums.gentoo.org/viewtopic-t-330321-highlight-reiser4.html  :Wink: 

----------

## tuxer

Ma queste discussioni secondo me lasciano un po' il tempo che trovano...

Rifare il portage non mi sembra molto sensato, e nemmeno riprogettarlo in un altro linguaggio, python è un ottima scelta secondo me!

Poi usare un db mi sembra un overhead eccessivo senza avere vantaggi eccessivi...

Ci sarebbero alcune cose  che mi piacerebbero nel portage, però niente di grave calcolando i tempi di esecuzioni con la mole di piccoli file da processare che si deve sorbire!

E poi alla fine se proprio si vuole cambiare qualcosa è meglio iniziare a programmare, se viene bene poi si può proporre, discutere non serve a molto  :Wink: 

----------

## neryo

 *tuxer wrote:*   

> 
> 
> E poi alla fine se proprio si vuole cambiare qualcosa è meglio iniziare a programmare, se viene bene poi si può proporre, discutere non serve a molto 

 

io sono conviento che la discussione e la progettazione sono le cose fondamentali per scrivere dei buoni programmi.. se si inizia subito a programmare ci si trova a dover imbattersi in problemi non piu' sanabili e quindi tornare a riscrivere intere applicazioni.  :Rolling Eyes: 

----------

## Ic3M4n

 *Quote:*   

> E poi alla fine se proprio si vuole cambiare qualcosa è meglio iniziare a programmare, se viene bene poi si può proporre, discutere non serve a molto

 

mi spiace ma questa è veramente una str*$£&ta. qualsiasi persona che abbia seguito un corso base di programmazione può citarti quale sia il ciclo di vita del software. e purtroppo (perchè come cosa sarebbe veramente fica) questa non è la programmazione.

----------

## tuxer

 *Quote:*   

> mi spiace ma questa è veramente una str*$£&ta. qualsiasi persona che abbia seguito un corso base di programmazione può citarti quale sia il ciclo di vita del software. e purtroppo (perchè come cosa sarebbe veramente fica) questa non è la programmazione.

 

Studio informatica e credo di saper programmare abbastanza bene e so benissimo qual è il ciclo di vita del sw...

Invece di iniziare a programmare allora diciamo iniziare a progettare o quello che vi pare, ma non sicuramente a perdere tempo dicendo questo non va bene questo fa schifo etc etc...

----------

## Ic3M4n

il che credo sia diverso rispetto a quello che hai detto prima.

----------

## tuxer

Certo è diverso ma pensavo si fosse capito cosa intendevo anche prima  :Rolling Eyes: 

Comunque la questione delle dipendenze inverse sarebbe certo comoda, però è una casino allucinante IMHO...

Freebsd non ha il concetto di slot e le versioni di python (per fare un esempio) sono viste come programmi "diversi", in gentoo con tutte le versioni di librerie e programmi che ci sono penso che le dipendenze inverse quasi raddoppierebbero il peso degli ebuild (e con non poche complicazioni) e non credo ne varrebbe la pena...

Il portage tree mi sembra già abbastanza corposo da syncare com'è adesso (e tenendo conto che può solo crescere)

----------

## stefanonafets

La soluzione migliore sarebbe indicizzare la struttura del file system (la parte di portage ovviamente) in un db ed ussare questo per le ricerche...

----------

## neryo

 *tuxer wrote:*   

> 
> 
> Invece di iniziare a programmare allora diciamo iniziare a progettare o quello che vi pare, ma non sicuramente a perdere tempo dicendo questo non va bene questo fa schifo etc etc...

 

Prima di iniziare a progettare cmq bisogna eliminare quello che fa schifo.. altrimenti come si fa a distinguerlo mentre si implementa?  :Wink:  Dopodiche' si inizia a progettare continuando  cmq a discutere..  :Razz: 

----------

## tuxer

Sì ma prima di dire fa schifo questo fa schifo l'altro è meglio conoscere come stanno le cose (come è fatto portage) e quali sono i reali problemi da affrontare, altrimenti sono parole campate per aria...

Poi fate un po' come vi pare  :Wink: 

----------

## Cazzantonio

 *tuxer wrote:*   

> penso che le dipendenze inverse quasi raddoppierebbero il peso degli ebuild (e con non poche complicazioni) e non credo ne varrebbe la pena...
> 
> Il portage tree mi sembra già abbastanza corposo da syncare com'è adesso (e tenendo conto che può solo crescere)

 

Unclepine già implementa un efficace metodo per gestire le dipendenze inverse... non mi sembra tutto questo problema  :Wink: 

Ok, unclepine non usa le funzioni di portage ma è scritto da zero.... per integrarlo in portage i developer magari lo vorrebbero riscrivere... ma il concetto rimane lo stesso

----------

## gutter

Mi sembra che la discussione stia andando un poco OT. 

Vediamo di tornare al discorso originale.

----------

## Cazzantonio

Perché OT? il titolo del topic non è "cosa dovrebbe cambiare in gentoo"?  :Rolling Eyes: 

----------

## tuxer

 :Confused:   in effetti mi pare ci sia un po' di paranoia nel cercare gli OT se devo essere sincero...

 *Quote:*   

> Unclepine già implementa un efficace metodo per gestire le dipendenze inverse... non mi sembra tutto questo problema  

 

Certo è efficace e appunto per quello sono d'accordo sul fatto che non servono le dipendenze inverse...

Nei ports di freebsd sono proprio all'interno dei makefile di ogni pacchetto, e per certe lib la lista è spaventosamente lunga...

----------

## shogun_panda

 *Cazzantonio wrote:*   

> Perché OT? il titolo del topic non è "cosa dovrebbe cambiare in gentoo"? 

 

Ehm...Veramente e' "Cosa dovrebbe cambiare in portage"... :Razz: 

Senno' iniziano discussioni del tipo basta con gli script SysV, basta con etc-update eccetera... (Occhio...Non e' che le caratteristiche che ho detto non mi piacciono...Sono le prime che ho pensato...)

----------

## earcar

 *X-Drum wrote:*   

> imho, come ha detto anche qualcuno, prima di una potenziale "ristrutturazione" di portage
> 
> adottando magari SQLite, che pur essendo minimale è un db SQL abb veloce (grazie è ridotto all'osso :PPP ),
> 
> bisognerebbe appunto introdurre in portage funzioni basilari come:
> ...

 

Quoto in toto, però aggiungo una cosa  :Razz: 

Python può essere esteso con moduli sviluppati in C, quindi molto più veloci dei moduli sviluppati in python.

L'idea è: perchè non sviluppare un modulo di ricerca e indicizzazione (stile eix) in C e integrarlo in portage?

Credo ci sarebbe un aumento di velocità non indifferente...

Tutto ciò IMHO

earcar  :Wink: 

----------

## gutter

 *Cazzantonio wrote:*   

> Perché OT? il titolo del topic non è "cosa dovrebbe cambiare in gentoo"? 

 

Mi riferivo ai 4 o 5 post prevedenti al tuo dove la discussione si era sopstata da emerge a come progettare in generale.

Edit: nel caso non fosse chiaro a cosa mi riferisco:

 *neryo wrote:*   

> 
> 
> io sono conviento che la discussione e la progettazione sono le cose fondamentali per scrivere dei buoni programmi.. se si inizia subito a programmare ci si trova a dover imbattersi in problemi non piu' sanabili e quindi tornare a riscrivere intere applicazioni. 

 

 *Ic3M4n wrote:*   

> 
> 
> mi spiace ma questa è veramente una str*$£&ta. qualsiasi persona che abbia seguito un corso base di programmazione può citarti quale sia il ciclo di vita del software. e purtroppo (perchè come cosa sarebbe veramente fica) questa non è la programmazione.

 

 *neryo wrote:*   

> 
> 
> Prima di iniziare a progettare cmq bisogna eliminare quello che fa schifo.. altrimenti come si fa a distinguerlo mentre si implementa?  Dopodiche' si inizia a progettare continuando  cmq a discutere.. 

 

----------

## fedeliallalinea

 *earcar wrote:*   

> L'idea è: perchè non sviluppare un modulo di ricerca e indicizzazione (stile eix) in C e integrarlo in portage?

 

Perche' mi pare che i developer vogliano tenere omogenita' per i tool integrati con portage

----------

## federico

Io sarei favorevole ad un portage in python con le procedure piu' ad alto consumo di prestazioni della macchina in C (è prassi in python questo connubio) e sarei favorevole anche ad una struttura a database, risparmiando spazio su disco e velocita' di calcolo (i tempi di accesso sulla grande quantita' di ebuild sono alti)

----------

