Lisp package guidelines (Italiano)

From ArchWiki
Revision as of 19:24, 2 May 2011 by Lorenzog (Talk | contribs) (Lisp-specific packaging)

Jump to: navigation, search


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 – فارسی

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Lisp package guidelines (Italiano)#)
Nota: Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.

Introduzione

Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.

Struttura delle cartelle e nomi

C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in /usr/share/common-lisp/source/gpg-error. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in /usr/share/common-lisp/source/. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.

La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.

Ad esempio, un pacchetto Lisp chiamato cl-ppcre' dovrebbe essere nominato cl-ppcre in AUR e risiedere in /usr/share/common-lisp/source/cl-ppcre. Un pacchetto chiamato alexandria dovrebbe essere nominato cl-alexandria in AUR e risiedere in in /usr/share/common-lisp/source/alexandria.

ASDF

Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti di sistema.

ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia /usr/share/common-lisp/systems/.

Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo:

# cl-ppcre.install
# arg 1:  the new package version
post_install() {
    echo "---> Compiling lisp files <---"

    clisp --silent -norc -x \
        "(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \
        (pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \
        (asdf:operate 'asdf:compile-op 'cl-ppcre)"

    echo "---> Done compiling lisp files <---"

    cat << EOM

    To load this library, load asdf and then place the following lines
    in your ~/.clisprc.lisp file:

    (push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)
    (asdf:operate 'asdf:load-op 'cl-ppcre)
EOM
}

post_upgrade() {
    post_install $1
}

pre_remove() {
    rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}
}

op=$1
shift

$op $*

Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...

pushd ${_lispdir}/systems
ln -s ../source/cl-ppcre/cl-ppcre.asd .
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .
popd

...dove $_lispdir è ${startdir}/pkg/usr/share/common-lisp. Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.

Packaging specifico per Lisp

Quando possibile, non creare pacchetti relativi ad una singola implementazione di lisp, cercare di essere cross-platform per quanto il pacchetto lo permetta. Se, nonostante tutto, il pacchetto è specificatamente pensato per una singola implementazione di lisp (ad esempio, gli sviluppatori non hanno ancora aggiunto il supporto per altre implementazioni, o il pacchetto è stato sviluppato per fornire una funzionalità già presente in altre implementazioni), è corretto fare il proprio pacchetto Arch specifico per una particolare implementazione di lisp.

Per evitare di creare pacchetti specifici per una particolare implementazione, idealmente i pacchetti relativi a tutte le implementazioni (SBCL, cmucl, clisp) dovrebbero essere creati con il campo del PKGBUILD common-lisp. Comunque, non è il caso (e questo potrebbe creare problemi alla persone che preferiscono avere implementazioni multiple di lisp a portata di mano). Allo stesso tempo, si potrebbe (a) non rendere il proprio pacchetto dipendente da nessun lisp e includere nel package.install un messaggio che richieda l'installazione di lisp (non ottimale) opppure (b) seguire l'esempio del PKGBUILD di sbcl e includere un controllo condizionale per capire quale lisp è necessario (che è una soluzione complessa e, ancora, non ottimale). Altre idee sono le benvenute.


Also note that if ASDF is needed to install/compile/load the package, things could potentially get awkward as far as dependencies go, since SBCL comes with asdf installed, clisp does not but there is an AUR package, and CMUCL may or may not have it (the author of this doc. knows next to nothing about CMUCL; sorry).

People currently maintaining lisp-specific packages that don't need to be lisp-specific should consider doing at least one of the following:

  • Editing their PKGBUILD(s) to be cross-platform, provided someone else is not already maintaining the same package for a different lisp.
  • Offering to take over maintenance or help with maintenance of the same package for a different lisp, and then combining them into a single package.
  • Offering up their package to the maintainer of a different lisp's version of the same package, so as to allow that person to combine them into a single package.

(Note that joyfulgirl, the author of this doc., currently maintains clisp versions of cl-ppcre and of stumpwm; she is open to either giving up the packages to the maintainers of the SBCL versions or to maintain the new, cross-platform versions herself if the SBCL-version maintainers don't want to).

Cose che l'utente può fare

  • Mantenere pacchetti lisp seguendo queste linee-guida.
  • Aggiornare e correggere queste linee-guida
  • Seguire i cambiamenti di questa pagina
  • Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone
  • Tradurre questa pagina e futuri aggiornamenti a questa pagina.