Difference between revisions of "Official repositories (Italiano)"

From ArchWiki
Jump to: navigation, search
m ([community-testing])
m (Cenni storici: minor spelling mistake)
Line 20: Line 20:
 
In passato, alcuni utenti non gradirono la selezione di Judd, così quando [[Arch Build System (Italiano) |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 passato, alcuni utenti non gradirono la selezione di Judd, così quando [[Arch Build System (Italiano) |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 prese solo da [core]. Questo infatti garantisce un sistema Linux completo, anche se potrebbe non essere quello desiderato.
+
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.
 
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.
Line 28: Line 28:
 
[http://aur.archlinux.org/ AUR] permette ai normali utenti di inviare i loro [[PKGBUILD (Italiano)|PKGBUILD]] per condividerli, se lo vogliono. Questi pacchetti non sono supportati e sono talvolta definiti repo '''[unsupported]''' sebbene, in quanto nessun pacchetto binario venga distribuito, questo non è un vero repository. I Trusted users possono adottare pacchetti da unsupported in [community] a loro discrezione, sia perchè il pacchetto è popolare sia perchè sono interessati a mantenerlo.
 
[http://aur.archlinux.org/ AUR] permette ai normali utenti di inviare i loro [[PKGBUILD (Italiano)|PKGBUILD]] per condividerli, se lo vogliono. Questi pacchetti non sono supportati e sono talvolta definiti repo '''[unsupported]''' sebbene, in quanto nessun pacchetto binario venga distribuito, questo non è un vero repository. I Trusted users possono adottare pacchetti da unsupported in [community] a loro discrezione, sia perchè il pacchetto è popolare sia perchè sono interessati a mantenerlo.
  
Dopo [http://www.archlinux.org/news/please-avoid-kernel-261614-1/ i numerosi problemi] causati dall'inserimento di un kernel in '''[core]''', fu introdotta la "core signoff policy", e 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] sono stati scarsamente utilizzati, 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 del repository [core] non fu mai chiaramente definita (semplicemente "pacchetti importanti, selezionati accuratamente dagli sviluppatori") - anche se alcuni sviluppatori richiedono "un frequente utilizzo da parte degli stessi, per garantirne l'autorizzazione" prima di inserirli in [core] - il repository è stato descritto più dettagliatamente [vedere più avanti].
+
Dopo [http://www.archlinux.org/news/please-avoid-kernel-261614-1/ i numerosi problemi] causati dall'inserimento di un kernel in '''[core]''', fu introdotta la "core signoff policy", e 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] sono stati scarsamente utilizzati, 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 del repository [core] non fu mai chiaramente definita (semplicemente "pacchetti importanti, selezionati accuratamente dagli sviluppatori") - anche se alcuni sviluppatori richiedono "un frequente utilizzo da parte degli stessi, per garantirne l'autorizzazione" prima di inserirli in [core] - il repository è stato descritto più dettagliatamente (vedere più avanti).
  
 
== [core] ==
 
== [core] ==

Revision as of 20:52, 28 August 2011

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Sommario help replacing me
I software repository contengono software compilato e confezionato dagli sviluppatori e dai Trusted Users, facilmente accessibile tramite pacman. Questo articolo delinea i repository ufficiali forniti e supportati dagli sviluppatori di Arch Linux.
Panoramica
I pacchetti in Arch Linux sono compilati utilizzando makepkg ed uno script personalizzato per ogni pacchetto (conosciutp come PKGBUILD). Una volta pacchettizzato, il software può essere installato e gestito con Pacman. I PKGBUILD per il software presente nei Repository Ufficiali sono disponibili da ABS; altre migliaia sono disponibili da Arch User Repository.
Wiki Correlati
Mirrors (Italiano)
Arch User Repository (Italiano)
Unofficial User Repositories

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 ai normali utenti di inviare i loro PKGBUILD per condividerli, se lo vogliono. Questi pacchetti non sono supportati e sono talvolta definiti repo [unsupported] sebbene, in quanto nessun pacchetto binario venga distribuito, questo non è un vero repository. I Trusted users possono adottare pacchetti da unsupported in [community] a loro discrezione, sia perchè il pacchetto è popolare sia perchè sono interessati a mantenerlo.

Dopo i numerosi problemi causati dall'inserimento di un kernel in [core], fu introdotta la "core signoff policy", e 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] sono stati scarsamente utilizzati, 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 del repository [core] non fu mai chiaramente definita (semplicemente "pacchetti importanti, selezionati accuratamente dagli sviluppatori") - anche se alcuni sviluppatori richiedono "un frequente utilizzo da parte degli stessi, per garantirne l'autorizzazione" prima di inserirli in [core] - il repository è stato descritto più dettagliatamente (vedere più avanti).

[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à:

  • 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 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).

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 (come openssh).
  • dipendono dai punti precedenti (ma non sono necessariamente makedepends).

Questo repository è incluso nel supporto di installazione core, in modo da poter costruire un sistema di base completamente funzionante senza accesso ad Internet.

[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]
Esempio: X.org, window managers, web servers, media players, linguaggi tipo Python, Ruby e molti altri.

[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.

[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.

[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 pacman.conf.

Il sistema potrebbe diventare instabile dopo un aggiornamento con [testing] abilitato e, per questo, solo utenti esperti dovrebbero usarlo.

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 del set dei pacchetti contenuti in [core], o per essere critici in altri modi. Come tale, gli utenti del repository [testing] sono caldamente invitati a iscriversi alla mailing list arch-dev-pubblico, 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] è similare al repository [testing], ma riguarda i pacchetti che sono candidati per entrare nel repository [community].

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

[unsupported] ossia AUR

[unsupported] è il repository basato sul web che viene comunemente chiamato 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. 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 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]

Repository non ufficiali degli utenti

Molti utenti hanno creato dei repository pubblici ma non ufficiali. Una lista di questi repository la si può trovare nella pagina unofficial user repositories.