Difference between revisions of "Official repositories (Italiano)"

From ArchWiki
Jump to: navigation, search
m (Cenni storici)
m
(11 intermediate revisions by one other user not shown)
Line 5: Line 5:
 
[[es:Official Repositories]]
 
[[es:Official Repositories]]
 
[[fr:Depots]]
 
[[fr:Depots]]
 +
[[ja:Official Repositories]]
 
[[nl:Official Repositories]]
 
[[nl:Official Repositories]]
 
[[pt:Official Repositories]]
 
[[pt:Official Repositories]]
Line 39: Line 40:
  
 
== [core] ==
 
== [core] ==
Il repository [core] si trova in ''core/os/i686'' o in ''core/os/x86_64'' nel proprio mirror preferito. Esso è sottoposto a rigidi requisiti di qualità:
+
Questo repository [core] può essere trovato in {{ic|.../core/os/}}, nel proprio mirror preferito.  
  
* sviluppatori e/o utenti hanno bisogno di un'autorizzazione per gli aggiornamenti dei pacchetti, prima che questi ultimi vengano accettati.
+
Esso è sottoposto a rigidi requisiti di qualità:
* per i pacchetti utilizzati di rado, è necessaria un'esposizione ragionevole (ad esempio: notifiche agli utenti degli aggiornamenti, richiesta di autorizzazioni, periodi di prova da pochi giorni ad una settimana, a seconda della rilevanza dei cambiamenti, la mancanza di segnalazioni di errori, insieme all'implicita autorizzazione del manteiner del pacchetto).
+
 
 +
* Sviluppatori e/o utenti hanno bisogno di un'autorizzazione per gli aggiornamenti dei pacchetti, prima che questi ultimi vengano accettati.
 +
* Per i pacchetti utilizzati di rado, è necessaria un'esposizione ragionevole (ad esempio: notifiche agli utenti degli aggiornamenti, richiesta di autorizzazioni, periodi di prova di una settimana, a seconda della rilevanza dei cambiamenti, la mancanza di segnalazioni di errori, insieme all'implicita autorizzazione del manteiner del pacchetto).
  
 
Esso contiene i pacchetti che:
 
Esso contiene i pacchetti che:
Line 50: Line 53:
 
* sono essenziali per la compilazione di altri pacchetti.
 
* sono essenziali per la compilazione di altri pacchetti.
 
* possono gestire e controllare/riparare i filesystems supportati.
 
* possono gestire e controllare/riparare i filesystems supportati.
* sono necessari nelle prime fasi del processo di installazione (come openssh).
+
* sono necessari nelle prime fasi del processo di installazione (ad esempio {{Pkg|openssh}}).
 
* dipendono dai punti precedenti (ma non sono necessariamente makedepends).
 
* dipendono dai punti precedenti (ma non sono necessariamente makedepends).
  
''Questo repository, utilizzato per essere incluso nel supporto di installazione core, in modo da poter costruire un sistema di base completamente funzionante senza accesso ad Internet, ora non è più necessario. L'accesso ad Internet è ora necessaria per installare un nuovo sistema.''
+
{{Nota|Questo repository, utilizzato per essere incluso nel supporto di installazione core, in modo da poter costruire un sistema di base completamente funzionante senza accesso ad Internet, ora non è più necessario. L'accesso ad Internet è ora necessaria per installare un nuovo sistema. Vedere [[Pacman_Tips#Installing_packages_from_a_CD.2FDVD_or_USB_stick|qui]] se si vuole creare un repository locale con pacchetti provenienti da [core] o da uno degli altri repository.}}
  
 
== [extra] ==
 
== [extra] ==
Il repository [extra] si trova in ''extra/os/i686'' o in ''extra/os/x86_64'' nel proprio mirror preferito. Contiene tutti i pacchetti che non sono contenuti in [core]<br>
+
Questo repository pu èssere trovato in {{ic|.../extra/os/}} nel proprio mirror preferito.  
Esempio: X.org, window managers, web servers, media players, linguaggi tipo Python, Ruby e molti altri.
+
 
 +
Esso contiene tutti i pacchetti che non sono contenuti in [core]. Esempio: Xorg, window managers, browser web, media players, strumenti per linguaggi tipo Python, Ruby e molti altri.
  
 
== [community] ==
 
== [community] ==
Il repository [community] si trova in ''community/os/i686'' o ''community/os/x86_64'' sul mirrror preferito. È mantenuto dai  ''Trusted Users (TUs)''  e fa parte di  ''Aur User Repository (AUR)''. Contiene i pacchetti da "AUR" che hanno avuto abbastanza voti e sono stati adottati da un ''TU''.
+
Questo repository può essere trovato in {{ic|.../community/os/}} sul mirrror preferito.  
 +
 
 +
Esso contiene i pacchetti provenienti dall'[[Arch User Repository (Italiano)|Arch User Repository]] che hanno avuto abbastanza voti e sono stati adottati da un [[Trusted_Users|Trusted User]].
  
 
== [multilib] ==
 
== [multilib] ==
  
Il repository [[multilib]] è reperibile su ''multilib/os/x86_64'' del mirror preferito. Contiene librerie 32 bit che possono essere utilizzate per eseguire applicazioni a 32 bit come il plugin flash e skype su installazioni a 64 bit.
+
Questo repository può essere trovato in {{ic|.../multilib/os/}} del mirror preferito.  
 +
 
 +
Esso contiene software a 32 bit e librerie che possono essere utilizzate per eseguire e sviluppare applicazioni a 32 bit su 64 bit (ad esempio {{Pkg|wine}}, {{Pkg|skype}}, ecc).
 +
 +
Per maggiori informazioni, vedere [[Multilib]].
  
 
== [testing] ==
 
== [testing] ==
Il repository [testing] si trova in ''testing/os/i686'' sul vostro mirrror preferito. [testing] è speciale: contiene i pacchetti che sono candidati per [core] o [extra].
 
I nuovi pacchetti vanno in [testing] se:
 
* si pensa che possano rovinare qualcosa durante un aggiornamento e hanno bisogno di essere testati prima.
 
* richiedono altri pacchetti per la ricompilazione. In questo caso, tutti i pacchetti che necessitano di ricompilazione sono messi prima in [testing] e vengono spostati di nuovo agli altri repo quando questa è stata effettuata.
 
  
[testing] è l'unico repo che può avere conflitti di nome con gli altri repo ufficiali e, se abilitato, deve essere il primo della lista nel file {{ic|/etc/pacman.conf}}.
+
{{Attenzione| Fare attenzione quando si abilita il repository [testing]. Il sistema potrebbe diventare instabile dopo l'esecuzione di un aggiornamento con [testing] abilitato e, per questo, solo utenti esperti dovrebbero usarlo.}}
  
{{Attenzione| Fare attenzione quando si utilizza [testing]. Il sistema potrebbe diventare instabile dopo un aggiornamento con [testing] abilitato e, per questo, solo utenti esperti dovrebbero usarlo.}}
+
Questo repository può essere trovato in {{ic|../testing/os/}} sul proprio mirrror preferito.
  
Il deposito [testing] non  è creato per contenere le ultimissime versioni dei pacchetti. Parte del suo scopo è quello di controllare gli aggiornamenti dei pacchetti che hanno il potenziale per causare la "rottura del sistema", sia per far parte del set dei pacchetti contenuti in [core], o per essere critici in altri modi. Come tale, gli utenti del repository [testing] sono "caldamente invitati" ad iscriversi alla mailing list [https://mailman.archlinux.org/mailman/listinfo/arch-dev-public arch-dev-public], a visitare il [testing] Repo Forum ed a segnalare tutti i bug al bug tracker.
+
Esso è speciale perchè contiene i pacchetti che sono candidati per i repository [core] o [extra].
  
Se si abilita testing, si deve abilitare anche community-testing.
+
I nuovi pacchetti vanno in [testing] se:
  
== [community-testing] ==
+
* Possano rovinare qualcosa durante un aggiornamento e hanno bisogno di essere testati prima.
 +
* Richiedono altri pacchetti per la ricompilazione. In questo caso, tutti i pacchetti che necessitano di ricompilazione sono messi prima in [testing] e vengono spostati di nuovo agli altri repo quando questa è stata effettuata.
  
Il repository [community-testing] è similare al repository [testing], ma riguarda i pacchetti che sono candidati per entrare nel repository [community].
+
Questo è l'unico repository che può avere conflitti di nome con gli altri repo ufficiali. Se abilitato, deve essere il primo della lista nel file {{ic|/etc/pacman.conf}}.
  
Se si abilita community-testing, si deve abilitare anche testing.
+
Si noti che non è creato per contenere le "ultimissime versioni" dei pacchetti. Parte del suo scopo è quello di controllare gli aggiornamenti dei pacchetti che hanno il potenziale per causare la "rottura del sistema", sia per far parte del set dei pacchetti contenuti in [core], o per essere critici in altri modi. Come tale, gli utenti del repository [testing] sono "caldamente invitati" ad iscriversi alla mailing list [https://mailman.archlinux.org/mailman/listinfo/arch-dev-public arch-dev-public], a visitare il [testing] Repo Forum ed a segnalare tutti i bug al bug tracker.
  
== [multilib-testing] ==
+
Se si abilita [testing], si deve abilitare anche [community-testing].
  
Il repository [multilib-testing] è simile a quello[testing] ma dedicato ai pacchetti candidati per il repository [multilib].
+
== [community-testing] ==
  
Se si abilita multilib-testing, si edve abilitare anche testing.
+
Il repository [community-testing] è come il repository [testing], ma riguarda i pacchetti che sono candidati per entrare nel repository [community].
  
==[unsupported] ossia AUR ==
+
Se lo si si abilita, si deve abilitare anche [testing].
[unsupported] è il repository basato sul web che viene comunemente chiamato [[AUR (Italiano)|AUR]], oppure Arch User Repository.* Gli utenti possono contribuire a tale repository inviando i pacchetti sorgente contenenti vari file di compilazione tra cui i [[PKGBUILD (Italiano) | PKGBUILD]]. Si tratta di un repository non ufficiale e non supportato che non è direttamente accessibile tramite pacman. Per installare un pacchetto dal repo [unsupported] l’utente deve scaricare ed estrarre il pacchetto sorgente, eseguire [[makepkg (Italiano)|makepkg]] che scarica i sorgenti e compila il pacchetto, ed infine installare quest’ultimo utilizzando pacman. Per maggiore aiuto consultare uno dei noti [[AUR Helpers]].
+
  
{{Nota|Tecnicamente, AUR è composto sia da [community] che da [unsupported]}}
+
== [multilib-testing] ==
  
== Repository non ufficiali degli utenti ==
+
Questo repository è come il repository [testing], ma dedicato ai pacchetti candidati per il repository [multilib].
  
Molti utenti hanno creato dei repository pubblici ma non ufficiali. Una lista di questi repository la si può trovare nella pagina [[Unofficial_User_Repositories|unofficial user repositories]].
+
Se lo si abilita, si edve abilitare anche [testing].

Revision as of 15:26, 2 January 2013

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end

Un software repository è un "magazzino" di dati da cui i pacchetti di software possono essere recuperati e installati su un computer. Gli Arch Linux package maintainers (sviluppatori e Trusted Users) mantengono un certo numero di repository ufficiali, contenenti i pacchetti del software, da quello più essenziale a quello extra, facilmente accessibili via pacman. Questo articolo delinea questi repository ufficialmente supportati.

Cenni storici

La maggioranza delle suddivisioni dei repository (depositi di software) esistono per motivi storici. Originariamente, quando Arch Linux era usata da pochissimi utenti, esisteva un solo repo, che ora è [core], chiamato [official]. Questo repository conteneva originariamente le applicazioni preferite di Judd Vinet, il creatore della distribuzione. Oggi è destinato a contenere un programma per ogni tipo di applicazione: un window manager, uno dei principali browser e così via.

In passato, alcuni utenti non gradirono la selezione di Judd, così quando Arch Build System diventò così semplice da usare cominciarono a creare pacchetti da soli. Questi pacchetti andarono in un repository chiamato [unofficial], che fu mantenuto da altri sviluppatori oltre Judd. Alla fine, i due repo vennero entrambi considerati ugualmente supportati dagli sviluppatori, cosicchè i nomi [official] e [unofficial] non erano più adatti; furono quindi rinominati rispettivamente [current] ed [extra] alla versione 0.5.

In breve tempo, dopo la versione 2007.8.1, [current] cambiò nome in [core] per evitare confusione su cosa esattamente contenesse. I due repo sono ora praticamente uguali agli occhi degli sviluppatori e della comunità, anche se [core] ha qualche differenza; la principale è che i pacchetti conenuti nell'Install CD e nelle release snapshots sono presi solo da [core]. Questo infatti garantisce un sistema Linux completo, anche se potrebbe non essere quello desiderato.

Tra le versioni 0.5 e 0.6, ci accorse che c'erano molti pacchetti che gli sviluppatori non volevano mantenere. Uno di questi (Xentac) preparò i "Trusted User Repositories", repo non ufficiali nei quali i Trusted Users (utenti fidati) potevano inserire i pacchetti da loro creati. Un repo, [staging], ospitava i pacchetti che potevano essere promossi da uno degli sviluppatori di Arch Linux per il passaggio ai depositi ufficiali ma, a parte questo, sviluppatori e Trusted Users restarono più o meno distinti.

Il sistema funzionò per un certo periodo, successivamente i Trusted Users cominciarono a trascurare i loro repo mentre dei normali utenti desideravano condividere i propri pacchetti. Questo portò allo sviluppo di AUR e i Trusted Users furono aggregati in un gruppo più unito che ora mantiene il repo [community]. I Trusted Users sono ancora un gruppo separato dagli svilupptori di Arch Linux e non c'è molto dialogo tra di loro. Comunque, i pacchetti più popolari sono ancora talvolta promossi da [community] ad [extra] AUR permette anche ai normali utenti di inviare PKGBUILDs.

Dopo i numerosi problemi causati dall'inserimento di un kernel in [core], fu introdotta la "core signoff policy". Da allora, tutti i pacchetti aggiornati per [core] devono necessariamente passare prima attraverso il repository [testing] e, solo dopo diverse autorizzazioni dei vari sviluppatori, possono muoversi nell'altro repo. Nel corso del tempo, si è notato che vari pacchetti [core] venivano utilizzati di rado, ciò, unitamente alla mancanza di segnalazioni di errori, divenne un criterio informale per l'accettazione dei pacchetti stessi.

Veso la fine 2009/inizio 2010, con l'avvento di alcuni nuovi filesystem (ed il desiderio di supportarli durante il processo di installazione), la realizzazione di [core] non fu mai chiaramente definita (semplicemente "pacchetti importanti, selezionati accuratamente dagli sviluppatori"); il repository è stato descritto più dettagliatamente (vedere più avanti).

[core]

Questo repository [core] può essere trovato in .../core/os/, nel proprio mirror preferito.

Esso è sottoposto a rigidi requisiti di qualità:

  • Sviluppatori e/o utenti hanno bisogno di un'autorizzazione per gli aggiornamenti dei pacchetti, prima che questi ultimi vengano accettati.
  • Per i pacchetti utilizzati di rado, è necessaria un'esposizione ragionevole (ad esempio: notifiche agli utenti degli aggiornamenti, richiesta di autorizzazioni, periodi di prova di una settimana, a seconda della rilevanza dei cambiamenti, la mancanza di segnalazioni di errori, insieme all'implicita autorizzazione del manteiner del pacchetto).

Esso contiene i pacchetti che:

  • sono necessari all'avvio di un qualsiasi sistema supportato da Arch.
  • possono essere necessari per connettersi ad internet.
  • sono essenziali per la compilazione di altri pacchetti.
  • possono gestire e controllare/riparare i filesystems supportati.
  • sono necessari nelle prime fasi del processo di installazione (ad esempio openssh).
  • dipendono dai punti precedenti (ma non sono necessariamente makedepends).
Nota: Questo repository, utilizzato per essere incluso nel supporto di installazione core, in modo da poter costruire un sistema di base completamente funzionante senza accesso ad Internet, ora non è più necessario. L'accesso ad Internet è ora necessaria per installare un nuovo sistema. Vedere qui se si vuole creare un repository locale con pacchetti provenienti da [core] o da uno degli altri repository.

[extra]

Questo repository pu èssere trovato in .../extra/os/ nel proprio mirror preferito.

Esso contiene tutti i pacchetti che non sono contenuti in [core]. Esempio: Xorg, window managers, browser web, media players, strumenti per linguaggi tipo Python, Ruby e molti altri.

[community]

Questo repository può essere trovato in .../community/os/ sul mirrror preferito.

Esso contiene i pacchetti provenienti dall'Arch User Repository che hanno avuto abbastanza voti e sono stati adottati da un Trusted User.

[multilib]

Questo repository può essere trovato in .../multilib/os/ del mirror preferito.

Esso contiene software a 32 bit e librerie che possono essere utilizzate per eseguire e sviluppare applicazioni a 32 bit su 64 bit (ad esempio wine, skype, ecc).

Per maggiori informazioni, vedere Multilib.

[testing]

Attenzione: Fare attenzione quando si abilita il repository [testing]. Il sistema potrebbe diventare instabile dopo l'esecuzione di un aggiornamento con [testing] abilitato e, per questo, solo utenti esperti dovrebbero usarlo.

Questo repository può essere trovato in ../testing/os/ sul proprio mirrror preferito.

Esso è speciale perchè contiene i pacchetti che sono candidati per i repository [core] o [extra].

I nuovi pacchetti vanno in [testing] se:

  • Possano rovinare qualcosa durante un aggiornamento e hanno bisogno di essere testati prima.
  • Richiedono altri pacchetti per la ricompilazione. In questo caso, tutti i pacchetti che necessitano di ricompilazione sono messi prima in [testing] e vengono spostati di nuovo agli altri repo quando questa è stata effettuata.

Questo è l'unico repository che può avere conflitti di nome con gli altri repo ufficiali. Se abilitato, deve essere il primo della lista nel file /etc/pacman.conf.

Si noti che non è creato per contenere le "ultimissime versioni" dei pacchetti. Parte del suo scopo è quello di controllare gli aggiornamenti dei pacchetti che hanno il potenziale per causare la "rottura del sistema", sia per far parte del set dei pacchetti contenuti in [core], o per essere critici in altri modi. Come tale, gli utenti del repository [testing] sono "caldamente invitati" ad iscriversi alla mailing list arch-dev-public, a visitare il [testing] Repo Forum ed a segnalare tutti i bug al bug tracker.

Se si abilita [testing], si deve abilitare anche [community-testing].

[community-testing]

Il repository [community-testing] è come il repository [testing], ma riguarda i pacchetti che sono candidati per entrare nel repository [community].

Se lo si si abilita, si deve abilitare anche [testing].

[multilib-testing]

Questo repository è come il repository [testing], ma dedicato ai pacchetti candidati per il repository [multilib].

Se lo si abilita, si edve abilitare anche [testing].