Newsgroup: it.comp.os.linux.software
Titolo: apt-cdrom add - come funziona ?

Come devo fare per poter aggiornare da cdrom ?
I pacchetti rpm si trovano in /mnt/cdrom/RedHat/RPMS/ .
[root@localhost root]# apt-cdrom add
Using CD-ROM mount point /mnt/cdrom/
Unmounting CD-ROM
Please insert a Disc in the drive and press enter 
Mounting CD-ROM
Identifying.. [73e3164dbb401446304fa655f9c1655f-2]
Scanning Disc for index files..  Found 0 package indexes and 0 source
indexes.
E: Unable to locate any package files, perhaps this is not a Conectiva
Disc
[root@localhost root]#
Hi! Sturmtruppen.
-- 
- Tu sai volare vecchio ?
- Che sciocchezza !! I lupi non volano. 
  Gli uccelli volano,i pesci nuotano e 
    i lupi se ne stanno con i piedi perterra!

 [root@localhost root]#
Ti piacerebbe se funzionasse cosě eh?!? No, troppo semplice:)
Il cdrom (o anche un archivio di rpm scaricati dalla rete..) deve essere 
organizzato in una maniera particolare, con una determinata struttura 
delle directory, disposizione dei files, poi ci devono anche essere i 
files con la descrizione dei pacchetti e altre cosette.
Probabilmente puoi partendo dal cdrom crearti un tuo repository sull'HD 
o su un altro. Il problema nasce dal fatto che la RH non supporta 
nativamente apt4rpm, quindi i cd non sono adatti a tale utilizzo.
Comunque sul sito di apt4rpm trovi un po' di documentazione (nemmeno 
tanta..) su come creareti un tuo repository.
Volevo farmelo anch'io ma non c'ho capito una sega:(
Ciao.
-- 
***  Per E-mail rimuovi ModE dall'indirizzo  ***
  *** Linux user # 198661 --- ICQ 33500725 ***
*** homepage 
http://web.tiscalinet.it/kailed
 ***
            *** Powered by Linux ***

 Volevo farmelo anch'io ma non c'ho capito una sega:(
non sei l'unico :)


non sei l'unico :)
si certo, creare una struttura di directory e lanciare uno script...
-- 
Maurizio - Tannoiser - Lemmo
STIGE Srl Servizi Informatici
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

 si certo, creare una struttura di directory e lanciare uno script...
certo come no. mi ricreo in duplice copia i cd degli aggiornamenti. I cd
costeranno pure 0,50€ ma non ho alcuna intenzione di averne una
quantita` doppia.
Tirate le somme ribadisco che se apt non e` capace di crearsi una lista, 
database o quello che piu` gli aggarda, dei cd che ho, semplicemente
sforzandosi di cercare in altre directory i pacchetti, bene apt lo posso
pure buttare al secchio.


quantita` doppia.
Ti basta farli fin da subito bene. qual'e` il problema? ti si formano
automagicamente nel masterizzatore? non credo. creerai prima il
repository su un hd della macchina che masterizza no? ti basta molto
poco per farli _fin_da_subito bene, ovvero sfruttabili con apt.
-- 
If NT is your answer, you don't understand the question


 si certo, creare una struttura di directory e lanciare uno script...
Mi daresti qualche info in più? Ho visto uno scriptino per RH (che non 
uso..) ma continuo a capirci poco. 
Bisogna utilizzare aptate?
Gli rpm vengono copiati automaticamente nelle varie directory o devo 
metterceli  a manina??
Ciao e grazie. 


> apt-get da rete funziona _benissimo_
Confermo..


A leggere questa discussione mi sorge spontanea una domanda...
<disclaimer> 
Ci sono le guerre degli sistemi operativi, le guerre degli editor, le
guerre dei linguaggi...  bastano e avanzano.  Quanto segue e` una
curiosita` sincera, per favore non scanniamoci e non tiriamo in ballo
questioni di religione.
</disclaimer>
La domanda e` rivolta a chi usa Red Hat e simili: per quali motivi
l'avete preferita a Debian?  Immediatezza di installazione?
Disponibilita` sui CD delle riviste?  Nome famoso?  O cosa?
(Il dubbio nasce dalla lettura periodica delle acrobazione rpm-esche e
dei tentativi di sopperire con soluzioni che vengono da Debian.)
Debianisti: devo ancora trovare uno tra voi che non sia pronto a
cantare le lodi di apt o la qualita` in generale della distribuzione,
percio` risparmiatevi, non mi direste nulla di nuovo. ;-P
Massimiliano
-- 
The Practical Penguin's Notebook - 
http://practicaltux.sourceforge.net
Guide per newbie pratiche al 100%: configurazione della posta
(Postfix, Fetchmail e Procmail), tutorial da zero su Mutt ed Emacs.
ManuaLinux: manuale di base in italiano by Panther

 percio` risparmiatevi, non mi direste nulla di nuovo. ;-P
Vedo che non hai capito comunque il senso del mio discorso :)
Non sto mettendo in dubbio le qualita` di apt, emi pare di averlo piu`
volte sottolineato. Sto semplicemente chiedendomi se ha senso
l'esistenza di apt4rpm, cioe` apt per una redhat. 
Punto.


 poco per farli _fin_da_subito bene, ovvero sfruttabili con apt.
aridajje.
ESEMPIO: ho una redhat 7.2 con gnome 1.4.0.4-38. Esce la RedHat 7.3 con
gnome 1.4.0.4-54. Voglio aggiornare gnome con i cd della distribuzione.
A botte di rpm ci metto poco ma divento scemo perche` la redhat ormai
sta su 3 cd e le dipendenze pure.
MAGIA: dico al buon apt di crearsi i suoi file su hd ma i pacchetti
stanno sotto /mnt/cdrom/Redhat/RPMS/ e poi gli dico di aggiornare gnome.
Il buon apt fa quello che gli pare (beh ... non esageriamo :) ma io
dall'esterno vedo solo che apt mi ciede un cd dopo l'altro.
RISULTATO: apt aggiunge funzioni interessanti a rpm.


Disponibilita` sui CD delle riviste?  Nome famoso?  O cosa?
Uso ambedue li distribuzioni in ambito professionale.
A parte quando decide il cliente (quasi mai, per fortuna), scelgo RH
quando si parte su applicativi che hanno in supporto RH. 
UDB2
Domino
WebSphere
prodotti per il quale, installare qualunque altra cosa non sia RH (o
suse, ma suse proprio non mi piace, se voglio un clone RH, mi tengo le
mie RH) significa cercarsi dei problemi (db2 e` rilasciato in
binario-rpm, e` IBM supporta le 4 distro-rpm-enabled, si potrebbe
"portare" i pacchetti con alien, ma francamente, la prima volta che hai
un problema ti arrangi. Arrangiarsi con i sorgenti si puo` pure fare,
con i binari inizia ad essere un po` troppo poco vantaggioso).
In tutti gli altri casi (web, mail, firewall ecc ecc ecc) uso Debian,
banalmente perche` e` piu` sysadmin oriented.
Nessun talebanismo, nessun principio de "il mio e` meglio del tuo".
Comodita`.


sta su 3 cd e le dipendenze pure.
ti basta inserire in source.list un url che abbia questi pacchetti
aggiornati (hints: freshrpms), e sei a posto.
Se chi fa i cd non ha interesse a supportare questo prodotto _non_ puo`
in nessun caso essere un problema del prodotto, ma mi sembra chiaro che
questo concetto ti e` assolutamente alieno.
-- 


metterceli  a manina??
Se sei pratico, funza come in debian (circa):
- ricrei la struttura delle directory.
- ci metti dentro i pacchetti (base e/o update a seconda)
- lanci lo scriptino che trovi sul sito che - come dpkg-scanpackages -
  quera tutti i bacchetti e crea il Packages.gz.
Finito.
Personalmente, non ho bisogno di crearmi un repository _mio_ per cui non
sento esattamente questa esigenza, tutti i miei server sono connessi in
rete.
Se avessi problemi di _banda_ preferisco mirrorare un repository (sui
vari siti ci sono le istruzioni per fare anche questo).


 writes:
[...]
Sturm> aridajje.  ESEMPIO: ho una redhat 7.2 con gnome
Sturm> 1.4.0.4-38. Esce la RedHat 7.3 con gnome 1.4.0.4-54. Voglio
Sturm> aggiornare gnome con i cd della distribuzione.  A botte di rpm
Sturm> ci metto poco ma divento scemo perche` la redhat ormai sta su 3
Sturm> cd e le dipendenze pure.
Che piffero sarebbero le dipendenze pure?
Sturm> MAGIA: dico al buon apt di crearsi i suoi file su hd ma i
Sturm> pacchetti stanno sotto /mnt/cdrom/Redhat/RPMS/ e poi gli dico
Sturm> di aggiornare gnome.  Il buon apt fa quello che gli pare (beh
Sturm> ... non esageriamo :) ma io dall'esterno vedo solo che apt mi
Sturm> ciede un cd dopo l'altro.
Allora il problema č solo questo? Si puň creare il Packages(.gz) su
disco facendo sě che i pacchetti rimangano su CD. Il come č una
questione di manuali (o 
groups.google.com
) e di porting dei tool
debian (apt-utils).
Sturm> RISULTATO: apt aggiunge funzioni interessanti a rpm.
Apt non aggiunge un bel nulla a rpm. Apt 'ste cose le fa nativamente.
Saluti
Marco

> Disponibilita` sui CD delle riviste?  Nome famoso?  O cosa?
Sturm> beh ... pero` provochi :)) inoltre ho dei ben precisi motivi
Sturm> per cui ho scelto redhat, non certo perche` c'ha il numero di
Sturm> release grosso. ma questo e` ot.
Non hai risposto, potresti farlo?
Non vedo quale altro gruppo potrebbe essere IT.
Ciao
Marco

  Apt non aggiunge un bel nulla a rpm. Apt 'ste cose le fa nativamente.
si, ma rpm no.
-- 
 ___     | (o_
 |_|     | //\
 | |ndry | V_/_ Linux Newbie (quasi User :-) ), Slackware 8.0 
         |       Linux User #221457

 francamente inizia ad essere indisponente.
tu sei sciroccato.
chi ha mai sparato merda su apt ?
cosa che invece stai facendo tu adesso.
Non continuo oltre. 
Sei fortunato che oggi sono calmo.


 Non vedo quale altro gruppo potrebbe essere IT.
non ne ho alcuna intenzione :) semplicemente la trovo piu` adatta alle
mie esigenze.
il discorso era nato su ben altri discorsi e non intendo diramare il
thread. :)


Non vedo quale altro gruppo potrebbe essere IT.
it.os.discussioni? o sort of... :)


 volte sottolineato. 
Mica sto dicendo che lo stai facendo, sto parlando di tutt'altro.


 banalmente perche` e` piu` sysadmin oriented.
Proprio il genere di informazioni che cercavo, importanti abbastanza
da far alzare il cartellino Warning al momento di installare per
esigenze specifiche.  Ti ringrazio.


Sei fortunato che oggi sono calmo.
sono tutto un brivido. Ma lascia perdere va la...
addio.


 dei tentativi di sopperire con soluzioni che vengono da Debian.)
Storia lunga, che vedrò di sintetizzare al massimo..
La mia prima esperienza con linux fu inizio '99 con un mdk 5.*, di Linux 
non sapevo assolutamente niente, praticamente non frequentavo i NG e 
ovviamente amici e parenti informatizzati usavo windows.
Inutile dire che fu una tragedia, l'installazione mi riuscì al primo 
colpo ma già la riconfigurazione di lilo per fare bootare anche 
windows, si rivelò un ostacolo insormontabile. Riformattai tutto un 
paio di volte e lasciai perdere.
Qualche giorno dopo, entrando quasi per caso in una grossa libreria di 
informatica nel centro di Milano, mi trovai davanti ad uno splendido 
scaffale con su diverse distro, RH, Suse e Caldera. La luce si 
riaccese, dopo uno studio di quasi un'ora optai per la Suse. Nessuna 
motivazione in particolare, semplicemente mi ispirava più delle altre.
Devo dire che la mia curva d'apprendimento fu decisamente rapida, e 
circa dopo una decina di giorni ero già su i NG a *rispondere* e a dare 
suggerimenti (LOL!).
Il fatto d'aver iniziato con una distro completa (tanti cd, manuali 
cartacei..), mi ha decisamente aiutato e se non ricordo male, non ho 
mai dovuto fare domande tipo "sono connesso ma non navigo".
Con la Suse mi sono sempre trovato bene e dalla 6.0 alla 7.3 le ho 
passate tutte. Ho provato, anche se molto velocemente, tutte la altre 
distro (tranne caldera, turbolinux e corel).
La RH (6.0) mi fece subito una brutta impressione, trovai pessimo il 
fatto di non utilizzare /opt per kde, gnome e netscape ma di schiaffare 
tutto sotto /usr. La Suse mi sembrava molto più ordinata.
Della Mdk ho provato la 7.2 (mi sembra), volevo vedere se c'era un 
effetto "pentium", ma mi parve decisamente più pesante della Suse, 
senza contare un paio di kernel panic di troppo per i miei gusti.
Veniamo alla Debian della quale ho provato la famosa "versione monca" 
distribuita un po' di tempo fa con 
inter.net
 (mi sembra). Nonostante 
l'incubo dselect, l'installai senza problemi.
Però mancavano un sacco di cose e complice anche la mia scarsa 
conoscenza della distro, ci combinai poco, dopo 2-3 giorni formattai la 
partizione, avevo anche bisogno di spazio per qualcosa che adesso non 
mi ricordo. Mi ripromisi però di riprovarla.
Di recente mi sono capitati i cd della 2.2r5 (quelli di Linux & C.) ma 
non ho nessuna voglia di fare due installazioni, una "base" da cd e una 
da rete per evere una distro aggiornata (xfree-4, kernel.2.4, kde3...).
Quindi apetterò la 3, con la speranza che non nasca già "vecchia".
Ho provato anche la RH 7.2 e la slack 8, ma su queste non esprimo 
commenti...
Trovo difficile utilizzare altre distro perché dopo 15 minuti che 
utilizzo una distro non configurata come voglio io, con tutte le cose 
al loro posto, con tutti i suoi segreti "rivelati", divento matto:)
Devo anche dire, che non vedo delle motivazioni valide per cambiare 
distro, con la Suse mi sono sempre trovato bene, ha sempre funzionato 
bene, non si è mai segnalata per una eccessiva quantità di bug, ha un 
ottimo supporto hardware e un'ottima dotazione software. E se magari le 
se può obiettare il fatto che, come le atre distro commerciali, 
rilascia delle nuove release molto (forse troppo) spesso, è anche vero 
che riesce a fare un bel mix tra programmi nuovi e programmi ben 
collaudati, senza buttarsi sull'ultima "feature" del momento come fa 
Mdk. Stesso discorso per i kernel Suse, mi sono sempre trovato 
benissimo, perfettamente funzionanti senza una esagerazione di patch.
Adesso uso il kernel ufficiale solo perché ho qualche problemino 
hardware sul portatile (apm/acpi) e provo sempre l'ultima stable per 
vedere se le cose migliorano....
Personalmente non ho mai avuto grossi problemi con gli rpm, bene o male 
avendo un po' di pratica/esperienza anche la gestione delle dipendenze 
non è poi così traumatica.
Ora c'è apt4rpm che anche se deve fare a cazzotti con i limiti dei 
pacchetti rpm, è innegabile che sia molto comodo, quindi se già mi 
trovavo bene prima e mi trovo ancora meglio adesso, perché dovrei 
cambiare distro???
Cosa ci guadagnerei passando (per esempio) a Debian?
Lo so qualcuno adesso dirà che la Suse è brutta e cattiva perché yast 
non è GPL, perché non rilascia più le iso (per x86) della propria 
distro...
Personalmente non condivido le scelte commerciali fatte da Suse anche se 
in piccola parte le capisco e credo anche che sia innegabile il 
contributo di Suse allo sviluppo di software libero (kernel, kde, x, 
reiser, etc,etc..), quindi comprare una Suse, vuol dire anche 
finanziare lo sviluppo del free software.
Ok, chiudo che mi sono dilungato anche troppo.


 pacchetti rpm, è innegabile che sia molto comodo,
Limiti l'rpm? A dire il vero non mi pare che abbia limiti. L'unico
limite che ha veramente e` quello che nessuno sembra saperlo usare
(neppure il suo creatore). Per il resto e` molto probabile che sia 
piu` potente di dpkg (ricordo che apt e` un frontend)
Henryx

 writes:
Henryx> Limiti l'rpm? A dire il vero non mi pare che abbia
Henryx> limiti. L'unico limite che ha veramente e` quello che nessuno
Henryx> sembra saperlo usare (neppure il suo creatore). Per il resto
Henryx> e` molto probabile che sia piu` potente di dpkg (ricordo che
Henryx> apt e` un frontend)
Apt _era_ un frontend, per il 90% adesso apt rimpiazza dpkg. Si
continua ad essere compatibili all'indietro perņ.
Saluti
Marco

 piu` potente di dpkg (ricordo che apt e` un frontend)
A parte la gestione pedestre delle dipendenze non posso che sorridere a
questa tua affermazione. Ma hai mai visto cosa si puo' fare con i vari
programmi della famiglia apt? Cose che rpm nemmeno vede in sogno.
-- 
- Le scaglie della mia corazza sono come scudi dieci volte piu' potenti
  i miei denti sono spade, i miei artigli lance, lo sferzare della 
  mia coda una saetta, le mie ali un uragano ed il mio alito MORTE !

 vari programmi della famiglia apt? Cose che rpm nemmeno vede in sogno.
..
Vero anche che apt č piů nuovo di rpm, quindi č anche normale che sia 
migliore. Partendo da 
apr4rpm.sourceforge.net
, si trovano diversi 
confronti tra apt e rpm.
Comunque rpm ha anche qualche vantaggio rispetto ad apt, puň per esempio 
installare/gestire diverse versioni dello stesso programma, almeno cosě 
ho letto.


 ho letto.
Non vedo l'utilita' della cosa se non incasinare il db.


piu` potente di dpkg (ricordo che apt e` un frontend)
Trovo, che quando si esprimono delle affermazioni del genere, sarebbe
quantomeno serio _motivare_.
Sentiamo gentilmente le tue motivazioni.
Per adesso accontentati delle mie:
rpm segue le dipendenze sui file e non sui pacchetti che e`
oggettivamente una fesseria.
rpm non supporta dipendenze lasce come "suggest" che sono invece molto
utili.
Non ci sono molti tool significativi per "pacchettizzare" sotto rpm.
rpm non gestisce le "importanze" su concetti di upgrade, preferenze,
ecc..


continua ad essere compatibili all'indietro perņ.
non e` vero. APT continua ad essere un front-end.
Il che non e` necessariamente un'affermazione negativa.


 Non vedo l'utilita' della cosa se non incasinare il db.
Non so se questo sia il caso adatto, ma ti faccio un esempio:
Il kde3 può essere installato parallelamente al kde2 se si usa rpm -i e 
NON rpm -U, apt in questo caso avrebbe rimpiazzato il kde2 con il kde3.
Penso però che il paragome tra rpm e apt non sia troppo giusto, apt è un 
programma aggiunto per la gestione dei pacchetti deb, sarebbe più 
giusto fare il confronto tra rpm e dpkg.


> continua ad essere compatibili all'indietro però.
Tanno> non e` vero. APT continua ad essere un front-end.  Il che non
Tanno> e` necessariamente un'affermazione negativa.
Da notare che non ho detto che non è più un front-end :-)
Stavo combattendo l'accezione negativa di front-end, ma hai ragione:
non è negativo front-end.
Ho detto che "era" per marcare il fatto che non è più realistico
utilizzare solo dpkg per gestire i pacchetti. In effetti si usa dpkg
solo per la parte finale del lavoro - quindi è un front-end - ma le
dipendenze vengono risolte prima da apt.
Anche l'elaborazione degli archivi di debs sono migrati su strumenti
basati su apt (c'entra nulla...).
Saluti
Marco

 writes:
[...]
Tanno> rpm segue le dipendenze sui file e non sui pacchetti che e`
Tanno> oggettivamente una fesseria.
Tanno> rpm non supporta dipendenze lasce come "suggest" che sono
Tanno> invece molto utili.
Tanno> Non ci sono molti tool significativi per "pacchettizzare" sotto
Tanno> rpm.
Tanno> rpm non gestisce le "importanze" su concetti di upgrade,
Tanno> preferenze, ecc..
In compenso rpm è più veloce di dpkg; mantiene in un db la lista dei
file (è l'unico motivo?).
Ha un meccanismo interno per il check degli archivi (in debian è
esterno AFAIK - debsums).
Posso aggiungere che con rpm può sembrare più facile creare pacchetti
- il che ha fatto in modo che anche cani e porci abbiano preteso di
fare il proprio pippo.rpm con risultati... (eufemismo) poco seri.
[da completare...]
Saluti
Marco

 piu` potente di dpkg (ricordo che apt e` un frontend)
Ti confondi con apt-get, e ti avevo corretto gia` un'ltra volta, a
riguardo.
APT e` il package tool; dpkg e` il programma che usa la rulebase di
APT. Quindi, e` dpkg il "frontend".
Basta leggere le manpage:
NAME
       apt - Advanced Package Tool
SYNOPSIS
       apt
DESCRIPTION
       APT  is  a management system for software packages.
[...]
NAME
       dpkg - a medium-level package manager for Debian
SYNOPSIS
       dpkg [options] action
DESCRIPTION
       dpkg  is a medium-level tool to install, build, remove and
       manage Debian GNU/Linux packages.
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 non e` vero. APT continua ad essere un front-end.
E` apt-get ad essere un frontend. APT e` il set di regole base per
gestire un pacchetto (descrizione, files e dipendenze).


 file (è l'unico motivo?).
No, usa un db binario, mentre APT usa un file di testo.
Il che, comunque lo si voglia vedere, e` un punto a favore di APT.


 find . -name *.rpm -exec rpm -Fvh {} \;
find . -name '*.rpm' -exec rpm -Fvh {} \;
ha ha che mi combini? :-))
ciao
P.S. se era giusto comincio a scappare per la vergogna :-)

 giusto fare il confronto tra rpm e dpkg.
Ed anche in questo caso non c'e' confronto, se non altro perche' e'
proprio la gestione dei pacchetti di RPM che e' perdente.


 gestire un pacchetto (descrizione, files e dipendenze).
Di cui fanno parte apt-cdrom, apt-move, apt-zip ecc..


ha ha che mi combini? :-))
non cambia nulla. *.rpm puoi farlo espandere alla shell o al find.
tant'e`:
[root@child root]# find . -name *.rpm
./kernel-source-2.4.9-31.i386.rpm
[root@child root]# find . -name '*.rpm'                 
./kernel-source-2.4.9-31.i386.rpm
[root@child root]# find . -name "*.rpm"
./kernel-source-2.4.9-31.i386.rpm


 ./kernel-source-2.4.9-31.i386.rpm
Non mi convince (scusa non posso fare prove)
Ma se nella directory c'è un file di quel tipo lo espande es
find . -name *.rpm
se c'è un file ciaciacia.rpm
il comando espando dalla shell non diventa:
find . -name ciaciacia.rpm??
dai non prendermi per fesso! :-)

 >ha ha che mi combini? :-))
cmq era una fesseria giusto per scrivere qualcosa...
cmq la risposta che mi hai dato tu funziona e fa quello che vuoi solo se
nella directory corrente e in tutte le sottodirectory o c'è un file rpm o
nessuno...
Se mi sbaglio corregimi
ciao

 decinaia e decinaia di Mbytes inutili?
Può essere utile, magari per provare una nuova versione di un programma 
senza eliminare quella, puoi fare un confronto diretto. Non è certo una 
features indinspensabile, ma può tornare utile..


 che su Debian funziona egregiamente)
In effetti sto usando abbastanza spesso il porting apt per rpm di
Madeinlinux e devo dire che mi sembra ben riuscito (ho dei problemi in
realtà, ma dipendono tutti dal fatto che mlx non ha tutti i mirror che
ha Debian). I comandi sono esattamente gli stessi, i file di
configurazione anche, il funzionamento impeccabile.
-- 
Registered user at 
http://counter.li.org
 # 170453
Jabber JID: 
sil...@jabber.linux.it
GnuPG Key fingerprint = 10E0 2B05 0B0A 3525 8760  788B 59B6 C74A 250E 65B6

 ./kernel-source-2.4.9-31.i386.rpm
Sicuro?  Mi sembra che in questo caso funzioni solo perche' c'e` un
file .rpm nella directory corrente.  La prima versione non troverebbe
file .rpm nelle sottodirectory.


 Ok, chiudo che mi sono dilungato anche troppo.
Grazie per averlo fatto.


 APT. Quindi, e` dpkg il "frontend".
Cosa intendi per rulebase?


 Madeinlinux e devo dire che mi sembra ben riuscito (ho dei problemi in
Ma ci sono proprio tutti i comandi della suite apt o solo una parte?


 features indinspensabile, ma puņ tornare utile..
Boh, de gustibus..


 Grazie per averlo fatto.
Di nulla, solo che mi sembra che il thread, anche se interessante, stia 
diventando un po' troppo OT..


per curiosita' ma tu mi hai killato?

 APT. Quindi, e` dpkg il "frontend".
Tratto da un file README-upgrade che si trovava in hamm:
	The Deity Project has developed a new and improved interface for
dpkg, known as apt.  The user interface for apt is not yet operational,
but it may be used from the command line and as an access method for
dselect.
Inoltre questa e` la descrizione del pacchetto apt:
Description: Advanced front-end for dpkg
 This is Debian's next generation front-end for the dpkg package manager.
 It provides the apt-get utility and APT dselect method that provides a
 simpler, safer way to install and upgrade packages.
Questo percio` imho sta a significare che le versioni di debian
precedenti ad hamm non avevano apt, e che apt e` un frontend di
dpkg, non il contrario (che invece e` cio` che vai affermando)
Henryx
P.S. se hai il cd di hamm, il readme lo trovi nella dir upgrade

 di apt.
La lista dei pacchetti e` sempre disponibile in formato testo,
`Packages.gz'. La cache binaria e` usata, appunto, come cache.
RPM usa proprio un DB binario, e proprio questo fatto ha creato problemi
nel passato tra RPM 3.x e RPM 4.x.


 Cosa intendi per rulebase?
Insieme di regole.


 Ma ci sono proprio tutti i comandi della suite apt o solo una parte?
A memoria: apt-get, apt-cache, apt-cdrom ci sono. Non ho provato
apt-proxy e simili, che del resto non ho mai usato nemmeno su Debian.
I file in /etc/apt/ (sources.list e preferences) sono uguali.


 apt-proxy e simili, che del resto non ho mai usato nemmeno su Debian.
C'è anche apt-file ma non l'ho ancora provato.


 peccato pero` che siano 4 o 5 file di testo per ogni pacchetto;
Sinceramente non ho mai sentito tutta questa penalizzazione di velocita'
usando dpkg e cmq sia preferirei anche questo ma avendo in cambio un
package manager che funzioni bene nel gestire le dipendenze. Chiedo
troppo?


 C'è anche apt-file ma non l'ho ancora provato.
Vabbe', poi bisognera' vedere appunto quanto il tutto funzioni e
sopratutto quanto e' supportato da chi rilascia pacchetti come qualcuno
ha scritto..


 writes:
[...]
Emmanuele> Dire "mantiene in un db la lista dei file" non e` affatto
Emmanuele> uguale a dire "mantiene un db binario".
Hai ragione, ma non è neppure completamente diverso :-)
IMHO la seconda affermazione è una raffinazione della prima. Io
intendevo evidenziare come dpkg non mantenga la lista di tutti i file
installati in unico db-file, ma invece utilizzi direttamente i file
.list di ciascun pacchetto, e che per questo la lettura di questa
lista - operazione necessaria più volte durante l'installazione
(...meno di prima) - sia più lenta. Con filesystem come ext2 'sta cosa
è tangibile quando il numero di pacchetti è importante.
$ ls -1 /var/lib/dpkg/info/ | wc -l
   8438
$ cat /var/lib/dpkg/info/*.list | wc -l
 176817
Emmanuele> La lista dei pacchetti e` sempre disponibile in formato
Emmanuele> testo, `Packages.gz'. La cache binaria e` usata, appunto,
Emmanuele> come cache.
Quindi convieni con me che se ci fosse tempo, denaro, e voglia si
potrebbe applicare questo stesso metodo a dpkg per migliorarne le
prestazioni?
Una sorta di dpkg-cache insomma (vedi dlocate); ovviamente straparlo
visto che non c'è ne tempo, ne denaro, anche se la voglia non
mancherebbe. Tra l'altro ho visto che è un argomento già affrontato
dal dpkg-team.
Emmanuele> RPM usa proprio un DB binario, e proprio questo fatto ha
Emmanuele> creato problemi nel passato tra RPM 3.x e RPM 4.x.
Sì, concordo meglio andare sul sicuro.
Saluti
Marco

 comprimesse tutto in un unico file via tar + gzip,
L'archivio con i metadati dei pacchetti installabili e` un solo file,
/var/lib/dpkg/available, l'archivio con i metadati dei pacchetti
installati e` anch'esso un solo file, /var/lib/dpkg/status.  File
contenenti il materiale installato da ogni pacchetto, script di pre- e
post- installazione e altre cosette, si trovano in /var/lib/dpkg/info/
e sono si` quattro o cinque file di testo per ogni pacchetto, ma
dubito che qualcuno rinuncerebbe al controllo e alla pulizia possibili
a favore dello spazio recuperabile.  Un file tar+gzip non e` una buona
soluzione, per fare un seek in uno stream gzippato devi decomprimere
tutto quel che precede il punto di arrivo; archiviarlo semplicemente
in tar non val la pena, son pur sempre blocchi da 512 byte (contro i
1024 del file system) e quindi un guadagno non apprezzabile,
considerando che un file singolo si corrompe piu` facilmente e ci
sarebbe bisogno, come anche tu fai notare, di un backup ad ogni
operazione.


 per curiosita' ma tu mi hai killato?
No, non pratico queste usanze, fatta eccezione per qualche spammer il
mio killfile e` deserto.
Massimiliano

 dpkg, non il contrario (che invece e` cio` che vai affermando)
C'e` un piccolo problema di fondo: per te, package manager e` il
programma che fisicamente opera sul pacchetto oppure quella serie di
strutture che definiscono le interazioni tra pacchetti e lo stato degli
stessi sul sistema?
Nel primo caso, il discorso che fai tu e` corretto: dpkg e` il package
manager.
Tuttavia, dire che il package manager si occupa solo di esplodere
l'archivio compresso e di mettere i file al loro posto, e` un errore:
a dpkg non gliene puo` fregar di meno di dove un file vada a finire, di
dipendenze complesse e di altre azioni che - quelle si - sono demandate
al package manager. Tutto quello che importa a dpkg e` avere in input un
pacchetto che risponde ad alcune regole base di struttura (formato di
compressione, dati all'interno, dipendenze semplici, script da eseguire).
Se fosse altrimenti, il check sulla conformita` di un pacchetto deb lo
farebbe dpkg, e non lintian, come, invece, avviene. Al contrario, chi
gestisce le dipendenze, si occupa di sapere dove i pacchetti sono
reperibili e quali pacchetti sono installati, di sciogliere le dipendenze
e di offrire una serie di algoritmi per evitare che il sistema degeneri
(cioe`, cio` che per me e` un package manage) e` APT.
Quindi, a me sembra che ci sia un po' di confusione tra il fine (un
package manager) e il mezzo (il programma che fisicamente va a toccare
un pacchetto deb). Con RPM non e` difficile: sia il programma che il
package manager hanno lo stesso nome. Se domani realizzassi un programma
alternativo a dpkg, con il nome apt, apt diventerebbe quindi il package
manager?
Hint: /usr/share/doc/apt/guide.txt.gz


 ha scritto..
Pensa che anche i mirror HTTP/FTP in sources.list devono avere la stessa
struttura di quelli debian, tipo:
rpm [mlx] 
ftp.madeinlinux.com/dists/4.0SE
 main
A rifletterci su, manco verrebbe la pena di usare RPM a questo punto. A
quanto ne so, l'intento della distribuzione (che mi sento di definire
buona, ma non posso garantire sulla stabilità perché da me gira su una
scheda madre modesta con la CPU che scalda parecchio, più driver binari
nel kernel, e penso che parecchi problemi vengano da lì) è di fornire
all'utente un sistema squisitamente efficente come APT ma fornire
compatibilità a livello di filesystem e gestore pacchetti con Red Hat,
per via della sua diffusione.


 qualcuno ha scritto..
Ovviamente, oltre ai limiti dei rpm, di cui si sta parlando in questo 
thread, c'è da considerare il fatto che attualmente solo Connectiva 
utilizza apt4rpm (il porting l'hanno fatto loro..), mentre RH, Mdk e 
Suse mi pare non stiano facendo nulla. Vedremo...


 Suse mi pare non stiano facendo nulla. Vedremo...
Sulle altre lo puoi installare a parte (per es. conosco chi l'ha messo
su RH) ma come si diceva, occorre vedere quanto la cosa e' supportata da
RH stessa ovvero quanti mirror che permettono quel tipo di aggiornamenti
vengono messi a disposizione altrimenti anche il miglior tool del mondo
e' perfettamente inutile.


 buona, ma non posso garantire sulla stabilità perché da me gira su una
Non so, ma definire buona la RH, specie alla luce delle ultime release
che in quanto ad affidabilita' non sono state eccelse io andrei cauto..
dicono che l'ultima, la 7.3, sia migliorata un pochino rispetto alle 2
precedenti (la 7.0 e' stato il fondo del pozzo) ma onestamente da quando
sono passato a Debian sarei un pazzo a tornare indietro.


 Non so, ma definire buona la RH, specie alla luce delle ultime release
Mi riferivo a Madeinlinux. Personalmente ritengo che l'ultima Red Hat
con una ben precisa connotazione fosse la 6.2, che considero anche il
vertice di qualità/prestazioni raggiunto.


 
Beh, *se* ci credono, Red Hat non avrebbe nessun problema a riempire il
pianeta di mirror.
Parlando di front-end a RPM, e per completare il quadro, qualcuno mi sa
dire com'è e come funziona urpmi di Mandrake? Io non l'ho mai usato, ma
ricordo un'articolo comparativo che confrontava le soluzioni RH e Mdk e
propendeva per quest'ultima.


 propendeva per quest'ultima.
No idea, ne avevo installata una ma non e' durata piu' di 24 ore.


 vertice di qualità/prestazioni raggiunto.
Ah ecco.. cmq si. concordo: l'ultima RH veramente usabile era
sicuramente la 6.2 anche se c'era qualche paccata di updates da
installare ma certamente meglio del tonfo delle 7.x


 No idea, ne avevo installata una ma non e' durata piu' di 24 ore.
Era quella volta che volevi vedere un'installazione di Hylafax
funzionante, per caso? :)


 funzionante, per caso? :)
No, mi serviva un OpenOffice veloce veloce per preparare delle slide per
una serie di speech che tenevamo col mio LUG ma dopo aver visto cio' che
faceva l'ho piallata all'istante.


 installare ma certamente meglio del tonfo delle 7.x
Dicono che la 7.3 sia stabile...
Henryx

 Dicono che la 7.3 sia stabile...
E' il condizionale che ti frega, e poi usando Debian a me...
