# Thread ufficiale su Paludis

## jordan83

THREAD UFFICIALE SU PALUDIS

Ho deciso di aprire questo thread in modo da fornire un luogo dove chi fosse interessato a tale packet manager può condividere esperienze e consigli.

Per chi non lo sapesse, Paludis è un gestore di pacchetti alternativo a Portage (è presente nel tree ufficiale, tutte le versioni sono in testing).

```
$ paludis -q paludis

* sys-apps/paludis

    gentoo:                0.12.0 0.14.0 {:0}

    paludis-overlay:       0.12.0 0.14.0 (scm)R {:0}

    installed:             0.14.0* {:0}

    Homepage:              http://paludis.pioto.org/

    Description:           paludis, the other package mangler

    License:               ( GPL-2 )

    Source origin:         sys-apps/paludis-0.14.0::paludis-overlay

    Installed time:        Wed Jan  3 14:48:46 2007

    Provides:              virtual/portage

    Use flags:             (bash-completion) (-contrarius) (-cran) (doc) (glsa) (-pink) (-qa) (ruby) (-selinux) (-zsh-completion)

Key to mask reasons:

* R: repository mask

```

QUI trovate il sito del progetto.

Giusto per stuzzicare la vostra curiosità  :Smile: , vi racconto la mia esperienza, così almeno chi vorrà provare avrà una base da cui partire.

 :Arrow:  Installazione

Ci sono due modi per passare a Paludis:

1) Partendo da una nuova installazione di Gentoo, eseguendo il bootstrap (vedi Bootstrap Howto)

EDIT: fare riferimento alla pagina del punto 2 anche in questo caso.

2) Migrando una installazione Gentoo esistente che (ovviamente) usa Portage (vedi Migration Howto)  :Wink: 

Io ho seguito il secondo metodo e devo dire che il passaggio a Paludis è stato assolutamente rapido e indolore.  :Smile: 

Seguendo l'howto il tutto si riduce a due comandi (dopo aver smascherato Paludis  :Wink:  ):

```
# emerge paludis

# ./portage2paludis.bash
```

Se tutto va a buon fine dovreste ritrovarvi con un Paludis e un Portage conviventi sullo stesso sistema, cosa confermata dal fatto che è comparsa una nuova cartella /etc/paludis nel cui contenuto:

```
$ ls /etc/paludis/

bashrc         licenses.conf  package_mask.conf    repositories

keywords.conf  mirrors.conf   package_unmask.conf  use.conf
```

è stata migrata la vostra configurazione di Portage.

 :Arrow:  Configurazione

Lo script portage2paludis.bash dovrebbe migrare tutto correttamente, e almeno nel mio caso non ci sono stati problemi.

I contenuti dei file di configurazione sono intuibili, in questa pagina trovate comunque una descrizione abbastanza dettagliata.

Particolarmente interessante è la cartella repositories, dove potete definire e aggiungere con estrema semplicità nuovi repository (alias overlay)

 :Arrow:  Primi passi

Dopo aver installato Paludis e averne controllato la configurazione, ho ovviamente deciso di smanettarci un po'.

Il sync dei repositories si esegue con:

```
# paludis --sync
```

La cosa che subito mi è balzata all'occhio è la fase finale del sync, quella in cui viene generata la cache degli ebuild. Con Paludis è stata portata a termine in modo pressoché immediato (pochi secondi), mentre normalmente Portage se la prende un attimino (!) più comoda.

Per aggiornare il sistema si da:

```
# paludis -pi world
```

e dopo aver controllato che i pacchetti siano di vostro gradimento si procede con

```
# paludis -i world
```

Se non ricordo male dopo la compilazione del primo pacchetto con Paludis, questo ha macinato un minuto buono per generare alcune variabili di configurazione interna. Questo, comunque, è successo solo la prima volta.

Alcune note:

- Paludis attiva di default quella che in make.conf è l'opzione test. Ciò probabilmente farà fallire alcune compilazioni, visto che non tutti gli ebuild gestiscono correttamente tale funzionalità. Io ho disabilitato tale funzionalità aggiungendo la riga:

```
SKIP_FUNCTIONS="test"
```

in /etc/paludis/bashrc. Fatto ciò non ho più riscontrato problemi.

- Controllate di avere in ordine i pacchetti smascherati in keywords.conf, facendo in modo che tutti abbiano il ~x86 alla fine. In caso contrario potreste avere problemi di generazione dipendenze (alcuni pacchetti potrebbero risultare non smascherati, cosa che potrebbe portare alla richiesta di downgrade).

- Paludis gestisce le dipendenze in modo piuttosto rigoroso. Nel mio caso ad esempio voleva "downgradare" le qt da 3.3.6-r4 a 3.3.6-r1 perché il pacchetto kdbg per qualche ignoto motivo sembrava richiedere le 3.3.6-r1. Ho eseguito l'upgrade di kdbg da 2.0.3 a 2.0.4 e tutto si è risolto.

- Quando volete ricompilare un pacchetto le dipendenze vengono automaticamente esaminate e, se necessario, si procede anche al loro upgrade (tipo quello che avviene con apt-get -i pacchetto per chi ha usato apt-get  :Wink:  ). Diciamo che di default l'opzione -D è settata. La gestione delle dipendenze può comunque essere opportunamente modificata settando degli appositi switch (man paludis o paludis -h e capirete di che sto parlando  :Smile:  )

Inserisco qui di seguito una traduzione dei comandi più comuni da emerge a paludis, per semplificare la vita a chi fosse interessato:

```

- ricerca pacchetto:                 emerge -s pacchetto / paludis -q pacchetto (N.B. per ricerche generiche usate eix o qsearch)

- installazione pacchetto:           emerge pacchetto    / paludis -i pacchetto

- installazione "empty-tree":        emerge -e pacchetto / paludis --dl-reinstall always -i pacchetto

- tipico aggiornamento sistema:      emerge -uDN world   / paludis --dl-reinstall if-use-changed -i world

```

 :Arrow:  Impressioni personali

Potete leggere sul sito del progetto le caratteristiche precise di Paludis e quello che gli sviluppatori vorrebbero farlo diventare. Da utente da circa una settimana, vi do le mie impressioni:

 PRO 

- veloce e reattivo

- stabile (pur essendo in fase di fervente sviluppo non ho riscontrato ancora problemi)

- possibilità di aggiornare singoli repository in modo agevole

- promette caratteristiche interessanti (ad esempio fetch di news dai repository) e facilità di estensione di funzionalità (ad esempio con gli hooks, script chiamati al verificarsi di determinate situazioni, tipo plug-in)

- compatibile con Portage

- facilità di aggiungere overlay/repository, con supporto a diversi tipi di connessione:

```
# paludis --list-sync-protocols

* file

* git

* git+http

* git+ssh

* rsync

* svn

* svn+http

* svn+https

* svn+ssh
```

 CONTRO 

- mancanza di wget resume (vedi FAQ). Secondo me è utile poter riprendere download dei pacchetti, soprattutto con connessioni lente  :Wink:  (EDIT: risolto nella 0.10)

- al momento assenza di parallel fetch 

- assenza di distlock (se state scaricando un pacchetto e un'altra istanza di Paludis prova a installarlo, questa fallirà miseramente).

 :Arrow:  Ultime considerazioni

Per chi volesse ulteriori info (tipo per capire come abilitare ccache) è stato aperto anche un wiki:

http://gentoo-wiki.com/HOWTO_Use_Portage_alternative_-_Paludis

- con Paludis è possibile usare le portage-utils ed eix (vedi wiki)

- Paludis un giorno dovrebbe implementare le funzionalità offerte da revdep-rebuild, per ora potete usare la versione che ho modificato che trovate seguendo il link nel wiki.

Per domande e discussioni usiamo questo thread, in modo da condividere le esperienze (positive e non  :Wink:  )

 :Exclamation:  RIASSUMENDO...  :Exclamation: 

 :Arrow:  HOME PAGE

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE #1 (chiuso perché troppo lungo)

 :Arrow:  THREAD UFFICIALE IN INGLESE #2

 :Arrow:  PLANET PALUDIS

EDIT 5/1/2007: piccoli aggiustamenti e aggiornamento degli indirizzi URL che sono stati cambiati.

EDIT 26/1/2007: aggiunta url planet paludise secondo thread ufficiale

----------

## lavish

Spostato da Forum di discussione italiano a Risorse italiane (documentazione e tools).

----------

## Cazzantonio

sembra interessante... ho dato anche una lettura alle faq del sito, tuttavia ancora non mi è chiaro in cosa dovrebbe essere diverso all'atto pratico

----------

## jordan83

 *Cazzantonio wrote:*   

> sembra interessante... ho dato anche una lettura alle faq del sito, tuttavia ancora non mi è chiaro in cosa dovrebbe essere diverso all'atto pratico

 

Dal lato utente ci sono diverse cose interessanti e che io ho concretamente provato.

Come dicevo:

> velocità

> gestione migliorata di overlay

> compatibilità completa con Portage.

Feature che danno del valore aggiunto sono queste (al momento  :Wink:  ):

> disinstallazione di un pacchetto e automaticamente delle sue dipendenze

> si può impostare che i pacchetti presi da repository SCM (CVS, subversion, ...) siano aggiornati automaticamente ogni "tot" giorni

> "hook" scripts che vengono attivati al verificarsi di determinate situazioni (funzionano un po' da plug-in)

> fetch di news dai repository, che tra i molti utilizzi che può avere sicuramente facilita la propagazione "capillare" tra gli utenti di avvisi e howto in caso di aggiornamenti importanti (pensa ad esempio all'aggiornamento di openssl o gcc)

> filtro pacchetti per licenza (magari a qualcuno piace avere solo GPL)

> parsing degli avvisi di sicurezza (GLSA)

Paludis è ancora in fase di sviluppo, ma già ora mi sembra praticamente equivalente a Portage (e questo lo dico da utente) e sotto molti aspetti migliore (la cosa ad esempio che salta agli occhi è la velocità  :Smile:  - non è che ci metta tempo 0, sia chiaro, ma è generalmente più scattante ).

In futuro tool come revdep-rebuild verranno integrati in Paludis stesso e in generale sono molte le novità che si potranno aggiungere con facilità.

Tutto questo, almeno dall'idea che mi sono fatto io non essendo uno sviluppatore di Paludis o di Portage  :Smile: , è dovuto principalmente al fatto che Portage ha un'architettura interna vetusta e difficilmente modificabile, cosa che rende ardua l'introduzione di nuove feature.

Paludis è stato sviluppato da gente che su Portage ci ha lavorato e che quindi sa abbastanza bene quali siano le cose da cambiare e quali necessitino particolare attenzione.

Considerando Paludis dal lato degli sviluppatori di ebuild, credo che le novità siano ancora più grosse e apprezzabili, dato che alcune feature erano attese da anni in Portage e semplicemente non potevano essere introdotte per problemi architetturali (al solito dico queste cose in quanto le ho lette in forum e nelle liste, quindi prendile col beneficio del dubbio  :Wink:  ). Ad esempio (cut&paste):

> :slot dependencies

> repository dependencies

> [use] dependencies

> Multiple inheritance for profiles.

> Ability to install hook scripts.

> Profile-level use forcing, globally and per-package, and from this the ability to specify a default in cases where one of n USE flags must be enabled.

Cose come [use] dependencies o repository dependencies oppure Multiple inheritance for profiles potrebbero semplificare la vita, e di molto, anche agli utenti  :Wink: 

Spero di aver risposto alla tua perplessità (o almeno di averti dato l'idea che io mi sono fatto)  :Smile: 

----------

## mouser

Una domandina veloce veloce da leccarsi le orecchie: Paludis è legato a portage o no??

Ti spiego, paludis utilizza alcune funzioni di portage, ecc. o ne può girare in maniera completamente indipendente (per esempio, su un sistema non costruito intorno al portage)?

Grazie dei chiarimenti

Ciriciao

mouser  :Wink: 

----------

## Cazzantonio

e anche una domandona da 1000 punti:

paludis è destinato in qualche modo ad essere integrato in gentoo (tipo soppiantando portage o magari venendo supportato in via ufficiale) oppure è destinato a rimanere un progetto non ufficiale di pochi volenterosi?

----------

## jordan83

 *mouser wrote:*   

> Paludis è legato a portage o no??
> 
> Ti spiego, paludis utilizza alcune funzioni di portage, ecc. o ne può girare in maniera completamente indipendente (per esempio, su un sistema non costruito intorno al portage)?
> 
> 

 

Paludis è completamente indipendente da Portage.

Paludis è infatti un'alternativa a Portage, non un'estensione.

È compatibile al 100% con il tree ufficiale, ma dico 99,99% solo perché non posso/voglio provare tutto il tree  :Wink: 

 *Cazzantonio wrote:*   

> e anche una domandona da 1000 punti: 
> 
> paludis è destinato in qualche modo ad essere integrato in gentoo (tipo soppiantando portage o magari venendo supportato in via ufficiale) oppure è destinato a rimanere un progetto non ufficiale di pochi volenterosi?
> 
> 

 

Come dici tu questa è davvero una bella domanda  :Smile: 

Per il supporto ufficiale/semiufficiale credo che nei prossimi mesi questo verrà "attivato".

C'era stata già a giugno la richiesta di un profilo "paludis" (che all'epoca era alla versione 0.2) che però cadde nel vuoto dopo una luuuunga discussione (cerca nelle liste) a causa del fatto che (in effetti) Paludis non era ancora una realtà sufficientemente concreta e gli sviluppatori Paludis (dal mio punto di vista) non si erano ancora confrontati abbastanza con gli altri sviluppatori Gentoo.  :Wink: 

Ora le cose sono cambiate, almeno per quanto riguarda la maturità di Paludis, sono quindi fiducioso che presto un profilo verrà reso disponibile...  :Wink: 

Relativamente alle possibilità di Paludis di soppiantare Portage... secondo me le carte in regola ce le ha.

Ciaranm, lo sviluppatore principale, ha nella firma nel forum le seguenti parole:

 *Quote:*   

> * Paludis 0.10, 127.35% Portage compatible and with all the features you wish Portage had.

 

Magari è un po' arrogante, ma se provi Paludis non puoi dire che abbia del tutto torto.

Paludis fa quello che fa Portage e non solo. È facile da estendere e migliorare e promette di semplificare la vita un po' a tutti.

Secondo me non può restare un progetto di nicchia, se uno lo prova si accorge che ha buone potenzialità  :Wink: 

Personalmente non ho ancora rimosso Portage solo perché mi serve etc-update (che potrei comunque soppiantare con conf-editor dopo un paio di modifiche ai sorgenti) e perché Portage fa da dipendenza per un tot di pacchetti importanti, come baselayout (ovviamente è solo una dipendenza "di comodo").

In un futuro spero prossimo, quando le cose verranno messe a posto, non esiterò di un secondo (a meno di motivi davvero gravi) a passare definitivamente a Paludis (= disinstallare Portage visto che uso solo Paludis già ora).

Se volete anche solo provarlo, potete farlo senza timori, in quanto se anche cambiaste idea e voleste tornare a Portage, vi basterà rimuovere la cartella /etc/paludis e dare un sync e tutto sarà come prima.

Come dicono nel sito, in caso di strani problemi con un pacchetto basterebbe disinstallarlo e riemergelo sotto Portage.

Se volete quindi provare e trovate problemi particolari o avete domande da fare o consigli da dare

QUI trovate il thread ufficiale in inglese e ovviamente sarebbe bello continuare la discussione anche nel nostro forum italiano.   :Smile: 

----------

## cloc3

L'aspetto meno efficiente di portage è, secondo me, la mancanza di strumenti di gestione sufficientemente efficienti e adeguatamente documentati.

Un esempio è la carenza di un tool per il controllo e la gestione delle dipendenze (non intendo disinstallare le dipendenze con il pacchetto stesso, che potrebbe essere arma a doppio taglio, ma semplicemente qualcosa come il famoso unclepine), ma in generale ho l'impressione che l'intero set delle gentoolkit sia piuttosto rigido e poco trasparente.

Paludis offre anche un pacchetto di programmi alternativo alle gentoolkit?

----------

## jordan83

 *cloc3 wrote:*   

> 
> 
> Paludis offre anche un pacchetto di programmi alternativo alle gentoolkit?

 

Dunque al momento ci sono Paludis e i tool che erano presenti per Portage e che sono stati portati a Paludis, quali:

- revdep-rebuild (del pacchetto gentoolkit)

- il pacchetto portage-utils

- eix

In futuro può essere che alcuni di questi (revdep-rebuild da quel che so praticamente di sicuro) verranno integrati in Paludis.

Quel che posso dire è che Paludis implementa una gestione delle dipendenze ben più avanzato di quello di Portage.

Non ho mai usato unclepine ma credo che molte delle cose che fa siano disponibili in Paludis:

Vi posto paludis --help così magari vi fate una idea di alcune delle opzioni:

```

$ paludis --help

Usage: paludis [options]

Actions:

  --query, -q            Query for package information

  --install, -i          Install one or more packages

  --uninstall, -u        Uninstall one or more packages

  --uninstall-unused     Uninstall unused packages

  --sync, -s             Sync all or specified repositories

  --report, -r           Report the current state of the system

  --contents, -k         Display contents of a package

  --owner, -o            Display the owner of a file

  --version, -V          Display program version

  --info, -I             Display program version and system information

  --help, -h             Display program help

More actions:

  --has-version          Check whether the specified atom is installed

  --best-version         Display the best version of the specified atom

  --environment-variable

                         Display the value of an environment variable for a particular package

  --configuration-variable

                         Display the value of a configuration variable for a particular repository

  --list-repositories    List available repositories

  --list-categories      List available categories

  --list-packages        List available packages

  --list-sets            List available package sets

  --list-sync-protocols  List available sync protocols

  --list-repository-formats

                         List available repository formats

  --list-dep-tag-categories

                         List known dep tag categories

  --update-news          Regenerate news.unread files

General options:

  --log-level            Specify the log level

      debug                Show debug output (noisy)

      qa                   Show QA messages and warnings only (default)

      warning              Show warnings only

      silent               Suppress all log messages

  --no-colour            Do not use colour

  --no-color             Alias for --no-colour

  --config-suffix, -c    Config directory suffix

  --resume-command-template

                         Save the resume command to a file made using mkstemp(3)

Query options:

  --show-deps, -D        Show dependencies

  --show-metadata, -M    Show raw metadata

Install, Uninstall options:

  --pretend, -p          Pretend only

  --preserve-world, -1   Don't modify the world file

  --no-config-protection

                         Disable config file protection (dangerous)

  --debug-build          What to do with debug information

      none                 Discard debug information (default)

      split                Split debug information

      internal             Keep debug information with binaries

  --fetch, -f            Only fetch sources; don't install anything

  --show-install-reasons

                         Show why packages are being installed

      none                 Don't show any information (default)

      summary              Show a summary

      full                 Show full output (can be very verbose)

  --with-unused-dependencies

                         Also uninstall any dependencies of the target that are no longer used

  --with-dependencies    Also uninstall packages that depend upon the target

DepList behaviour:

  --dl-reinstall         When to reinstall packages

      never                Never (default)

      always               Always

      if-use-changed       If USE flags have changed

  --dl-reinstall-scm     When to reinstall scm packages

      never                Never (default)

      always               Always

      daily                If they are over a day old

      weekly               If they are over a week old

  --dl-upgrade           When to upgrade packages

      always               Always (default)

      as-needed            As needed

  --dl-installed-deps-pre

                         How to handle pre dependencies for installed packages

      pre                  As pre dependencies

      pre-or-post          As pre dependencies, or post depenencies where needed

      post                 As post dependencies

      try-post             As post dependencies, with no error for failures

      discard              Discard (default)

  --dl-installed-deps-runtime

                         How to handle runtime dependencies for installed packages

      pre                  As pre dependencies

      pre-or-post          As pre dependencies, or post depenencies where needed

      post                 As post dependencies

      try-post             As post dependencies, with no error for failures (default)

      discard              Discard

  --dl-installed-deps-post

                         How to handle post dependencies for installed packages

      pre                  As pre dependencies

      pre-or-post          As pre dependencies, or post depenencies where needed

      post                 As post dependencies

      try-post             As post dependencies, with no error for failures (default)

      discard              Discard

  --dl-uninstalled-deps-pre

                         How to handle pre dependencies for uninstalled packages

      pre                  As pre dependencies (default)

      pre-or-post          As pre dependencies, or post depenencies where needed

      post                 As post dependencies

      try-post             As post dependencies, with no error for failures

      discard              Discard

  --dl-uninstalled-deps-runtime

                         How to handle runtime dependencies for uninstalled packages

      pre                  As pre dependencies

      pre-or-post          As pre dependencies, or post depenencies where needed (default)

      post                 As post dependencies

      try-post             As post dependencies, with no error for failures

      discard              Discard

  --dl-uninstalled-deps-post

                         How to handle post dependencies for uninstalled packages

      pre                  As pre dependencies

      pre-or-post          As pre dependencies, or post depenencies where needed

      post                 As post dependencies (default)

      try-post             As post dependencies, with no error for failures

      discard              Discard

  --dl-circular          How to handle circular dependencies

      error                Raise an error (default)

      discard              Discard

  --dl-fall-back         When to fall back to installed packages

      as-needed-except-targets Where necessary, but not for target packages

      as-needed            Where necessary, including for target packages (default)

      never                Never

List options:

  --repository           Matches with this repository name only

  --category             Matches with this category name only

  --package              Matches with this package name only

  --set                  Matches with this package set name only

Owner options:

  --full-match           Match whole filename

```

Qualche combinazione di rilievo e ad esempio non presente in portage (se lo fosse correggetemi  :Wink:  ) può essere:

```
paludis --with-dependencies -u pkg
```

disinstallerà pkg portandosi dietro i pacchetti che da lui dipendono

```
paludis --with-unused-dependencies -u pkg
```

disinstallerà pkg portandosi dietro le dipendenze inutilizzate (in un colpo fa il depclean per il pacchetto insomma)

```
paludis --show-install-reasons summary  -pi world
```

vi mostrerà i pacchetti che verranno installati per upgradare world spiegandovi perché li vuole installare

```
paludis --report
```

farà un check del vostro sistema elencandovi pacchetti potenzialmente insicuri, mascherati o che saranno rimossi a breve

```
paludis --pretend --install --dl-upgrade as-needed security
```

vi stamperà quali pacchetti verranno upgradati a causa di problemi di sicurezza (glsa)

```
paludis --dl-reinstall-scm weekly
```

upgraderà i pacchetti che avete preso dal cvs automaticamente ogni settimana (tipo E17  :Wink:  )

N.B. molte opzioni, ad esempio quest'ultima, non occorre che le editiate ogni volta. Basta impostare nel file di configurazione apposito, /etc/paludis/bashrc la variabile PALUDIS_OPTIONS  con i comandi che volete siano lanciati ogni volta.  :Smile: 

EDIT: piccolo errore, la variabile PALUDIS_OPTIONS va posizionata nel bashrc dell'utente, non in /etc/paludis/bashrc. Nel caso di root (indovinate un po'...  :Smile:  ) /root/bashrc

La lista potrebbe probabilmente continuare ancora un po', basta dare un'occhiata alle possibilità di configurazione delle dipendenze rese possibili da tutti gli switch che iniziano così: --dl-*

In sostanza ci sono parecchi spunti interessanti, e ogni giorno (vabbé, esagero, quasi ogni giorno  :Laughing:  ) se ne aggiungono di nuovi.  :Wink: 

Senza contare che uno degli obiettivi è quello del progetto è fornire una buona interfaccia ai programmatori per facilitare la realizzazione di applicazioni che sfruttino le potenzialità di Paludis. Questa è un'altra delle cose che si criticano a Portage e che di fatto rende più arduo del dovuto interfacciarvisi con altre applicazioni.

----------

## jordan83

Posto per segnalare l'uscita di Paludis 0.12

Queste le novità:

 *Quote:*   

> Changes since 0.10.1 include:
> 
> - The QA library now has a Ruby interface.
> 
> - Packages named -live are now recognised as SCM packages.
> ...

 

Come vedete è possibile attivare un nuovo sistema di caching che promette buone prestazioni (spero di confermarle quando l'avrò provato).

 :Arrow:  HOME PAGE di Paludis

 :Arrow:    Alcuni BENCHMARKS sul nuovo sistema di caching. Abbastanza terra-terra ma interessanti (uno di quelli del sito):

```

Command                                   Cold Cache           Hot Cache

---------                                ----------            ---------

paludis --query vim                         1.54                   0.17

pquery --all-repos --verbose vim           10.30                    0.64

equery list -p -o -e vim                   13.62                    1.41
```

 :Arrow:  Thread ufficiale in inglese

 :Arrow:    (EDIT) WIKI su gentoo-wiki.com.

----------

## cloc3

 *jordan83 wrote:*   

> 
> 
> Senza contare che uno degli obiettivi è quello del progetto è fornire una buona interfaccia ai programmatori per facilitare la realizzazione di applicazioni che sfruttino le potenzialità di Paludis. Questa è un'altra delle cose che si criticano a Portage e che di fatto rende più arduo del dovuto interfacciarvisi con altre applicazioni.

 

convincente e interessante.

mi pare che la gestione delle keywords e delle use avvenga in singoli file. La cartella /etc/portage, gestibile in sottodirectory, mi sembrava più comoda per l'utente finale.

----------

## jordan83

 *cloc3 wrote:*   

> 
> 
> mi pare che la gestione delle keywords e delle use avvenga in singoli file. La cartella /etc/portage, gestibile in sottodirectory, mi sembrava più comoda per l'utente finale.

 

Da quel che mi risulta i file sono solo due (se ho capito bene a che ti riferisci).   :Confused: 

I miei ad esempio sono (almeno in parte):

/etc/paludis/keywords.conf

```

# keywords.conf

# This file created by portage2paludis.bash

* x86

#Qemu

app-emulation/qemu-user ~x86

app-emulation/qemu ~x86

app-emulation/qemu-softmmu ~x86

app-emulation/kqemu ~x86

#Misc

x11-misc/googleearth ~x86

net-im/skype ~x86

kde-misc/katapult ~x86

net-libs/ortp ~x86

net-p2p/mldonkey ~x86

...

```

La prima riga specifica la keyword valida per tutti, cioé x86, le successive invece specificano le eccezioni.

/etc/paludis/use.conf

```

# use.conf

# This file created by portage2paludis.bash

* Xaw3d a52 aac acpi ada addbookmarks aiglx alias amr asf async audiofile automount autoreplace bash-completion bidi bl bzip2 cdparanoia cjk connectionstatus contactnotes cpudetection css curl cvs dbx dga divx doc dts dvdread emacs ethereal exif fat fbcon fbsplash ffmpeg flac gadu gatos gd glsa glut gmedia gmp gphoto2 gs gzip haskell highlight history icq idea idn imagemagick imlib irc jabber java javascript jingle jpeg2k kqemu latex lcms live logitech-mouse logrotate lzo madwifi matroska mbox mime mjpeg mmx mmxext mng mplayer msn musepack musicbrainz network nowin nowlistening nsplugin offensive openexr pascal pcmcia pdf php rar real realmedia ruby samba slang sms speex sql sse sse2 statistics stats subversion svg svga tetex texteffect theora tidy tiff translator usb userlocales utempter vcd vidix visualization webpresence wifi winpopup wmp xcomposite xine xosd xscreensaver xvid yahoo -cairo -eds -emboss -esd -gnome -isdnlog -pppd

* INPUT_DEVICES: keyboard mouse synaptics

* LINGUAS: en it

* VIDEO_CARDS: radeon vesa fbdev

app-office/lyx -gtk

x11-libs/qt examples

x11-libs/evas cairo

net-p2p/mldonkey magic

app-portage/portage-utils paludis

x11-libs/gtk+ -doc

```

ancora una volta le righe che iniziano con l'asterisco (* = tutti i pacchetti) specificano use valide per tutti, sotto invece si specificano le "eccezioni".

Personalmente trovo la cosa più razionale che in Portage, visto che qui a un dato file viene dato un solo specifico scopo.

Poi è e sempre sarà questione di gusti. Sicuramente c'è chi si trova meglio così e chi si trova meglio con il sistema Portage. Il mondo è bello perché è vario, no?  :Smile: 

Già che ci sono vi posto il mio /etc/paludis/bashrc sempre per darvi un'idea di come è fatto Paludis:

```
# bashrc

# This file created by portage2paludis.bash

export CHOST="i686-pc-linux-gnu"

export CFLAGS="-march=pentium4 -O2 -pipe"

export CXXFLAGS="-march=pentium4 -O2 -pipe"

export MAKEOPTS="-j2"

SKIP_FUNCTIONS="test"

#ccache

export PATH="/usr/lib/ccache/bin:$PATH"

export CCACHE_DIR="/var/tmp/ccache/"

export CC="/usr/lib/ccache/bin/gcc"

export CXX="/usr/lib/ccache/bin/g++"

```

----------

## cloc3

 *jordan83 wrote:*   

> 
> 
> /etc/paludis/keywords.conf
> 
> ```
> ...

 

mi sa che qui c'è la risposta.

I file di configurazione sarebbero (sto facendo il download il download, ma non ho ancora smanettato) gestibili tramite un apposito tool, mentre portage dava agli utenti la possibilità di gestire manualmente in un albero di directory (tipo /etc/portage/package.keyword/... )

----------

## jordan83

 *cloc3 wrote:*   

> 
> 
> I file di configurazione sarebbero (sto facendo il download il download, ma non ho ancora smanettato) gestibili tramite un apposito tool, mentre portage dava agli utenti la possibilità di gestire manualmente in un albero di directory (tipo /etc/portage/package.keyword/... )

 

Ah.. questa cosa di Portage la scopro ora   :Shocked: 

Non so se in Paludis si possa fare altrettanto. Questa info mi manca   :Rolling Eyes: 

----------

## cloc3

 *jordan83 wrote:*   

> 
> 
> Ah.. questa cosa di Portage la scopro ora  
> 
> Non so se in Paludis si possa fare altrettanto. Questa info mi manca  

 

Ahi. credo proprio di no. ho smanettato e devo smentire quello sche pensavo prima.

mi pare che portage2paludis.bash non riconosca le strutture di ricorsive di /etc/portage/* .

infatti la mia /etc/paludis creata in automatico non ne tiene conto.

se installassi qualcosa con paludis farei certamente dei pasticci tremendi.

----------

## jordan83

 *cloc3 wrote:*   

> 
> 
> infatti la mia /etc/paludis creata in automatico non ne tiene conto.
> 
> se installassi qualcosa con paludis farei certamente dei pasticci tremendi.

 

Mi sa che l'unica è creare i files a mano in questo caso.

Se ti serve aiuto posso dirti dove va la "roba", anche se credo che tu l'abbia più o meno intuito  :Smile: 

La struttura dei file è simile, almeno in buona parte, a quella di Portage.

----------

## cloc3

[quote="jordan83"] *cloc3 wrote:*   

> 
> 
> infatti la mia /etc/paludis creata in automatico non ne tiene conto.
> 
> se installassi qualcosa con paludis farei certamente dei pasticci tremendi.

 

Mi sa che l'unica è creare i files a mano in questo caso.

chiaramente il problema non è grave, e non è nemmeno un problema diretto di paludis, ma dello scriptino di migrazione.

solo che sarebbe opportuno richiedere a paludis una funzionalità analoga a quella di portage, perchè è utile per organizzarsi.

io, per installare paludis, ho dato:

```

forcekeymask -fm paludis

```

e forcekeymask mi ha chiesto il nome del file da generare:

```

s939 ~ # cat /etc/portage/package.keywords/paludis

dev-cpp/libebt

dev-libs/pcre++

dev-cpp/libwrapiter

```

adesso io so esattamente come e perché quei pacchetti sono stati smascherati e non me lo posso dimenticare.

inoltre, mi piacerebbe capire quali sono le funzioni di paludis (se esistono) che emulano forcekeymask (senza i corrispondenti problemi  :Smile:  ).

naturalmente, tutto ciò non per critica, ma perchè queste sono probabilmente le prime domande del nubbio quando utilizza il nuovo programma.

----------

## jordan83

 *cloc3 wrote:*   

> 
> 
> io, per installare paludis, ho dato:
> 
> ```
> ...

 

Capisco.

Puoi sempre creare "sezioni" nel file keywords.conf, un po' come ho fatto io:

```

#Frozen-bubble

games-arcade/frozen-bubble ~x86

media-libs/sdl-pango ~x86

#Paludis

sys-apps/paludis ~x86

dev-cpp/libwrapiter ~x86

dev-cpp/libebt ~x86

app-portage/portage-utils ~x86

#Mono

dev-lang/mono ~x86

dev-dotnet/libgdiplus ~x86

...

```

non è lo stesso ma comunque ti permette di individuare che pacchetti hai smascherato per installarne uno particolare.

 *cloc3 wrote:*   

> 
> 
> inoltre, mi piacerebbe capire quali sono le funzioni di paludis (se esistono) che emulano forcekeymask (senza i corrispondenti problemi  ).
> 
> naturalmente, tutto ciò non per critica, ma perchè queste sono probabilmente le prime domande del nubbio quando utilizza il nuovo programma.

 

temo di doverti deludere ma non mi pare che Paludis offra tali funzionalità.

Devi tenere conto che il progetto è giovane e comunque al momento ci sono altre priorità rispetto a funzioni "di contorno" (che comunque non dico non siano importanti).

Utility come forcekeymask esulano dalle funzionalità "core" di un gestore di pacchetti.

Col tempo tali script salteranno fuori, mano a mano che Paludis verrà utilizzato di più.

Per dire, al momento mancano anche utility per le useflag come ufed. Ci vuole un po' di tempo  :Wink: 

----------

## jordan83

Paludis 0.14.0

Queste le novità:

 *Quote:*   

> 
> 
> - The merge and unmerge utilities are now called with an explicit path. 
> 
> - The documentation has been tidied up and extended. Documentation for the Ruby interface is now available. paludis --report now also reports unused packages. 
> ...

 

Da notare inoltre che l'url dell'home page è cambiata in http://paludis.pioto.org/

È stata aggiunta una interessante sezione FAQ.

Paludis supporta ora anche i repository CRAN (vedi http://cran.r-project.org/ ). A breve saranno supportati anche quelli GEMS (vedi http://rubyforge.org/projects/rubygems/ ).

Un paio di feature interessanti lato utente aggiunte in questa versione sono:

- il miglioramento della funzionalità di --report he ora segnala anche i pacchetti installati ma inutilizzati presenti nel sistema;

- il tool contrarius per gestire cross-compilazioni

- la possibilità di farsi stampare a video la spiegazione delle use flag dei pacchetti che si stanno per installare con lo switch --show-use-descriptions

```
  --show-use-descriptions

                         Show descriptions of USE flags

      none                 Don't show any descriptions (default)

      new                  Show for new use flags

      changed              Show for new and changed flags

      all                  Show for all flags
```

che non credo richieda altri commenti esplicativi.

 :Arrow:  HOME PAGE

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE

----------

## jordan83

Paludis 0.14.2

In pochi giorni sono uscite due nuove versioni, raccolgo in questo post entrambe.

Queste le novità della 0.14.1:

 *Quote:*   

> - Versions can include -rx.y, -rx.y.z etc. 
> 
> - Paludis can now be told to pull in new slots only where really necessary, via --dl-new-slots as-needed. This must be used in conjunction with the existing --dl-upgrade. 
> 
> - Paludis can now uninstall all versions of a package by --uninstall --all-versions. 
> ...

 

Queste le novità della 0.14.2:

 *Quote:*   

> - Various performance tweaks. 
> 
> - keywords.conf can now use * to accept packages that brokenly set only "-*" in KEYWORDS. 
> 
> - Installing and uninstalling set*id files is now done differently to prevent exploitation of supposedly uninstalled vulnerable applications. 
> ...

 

Ritengo particolarmente degna di nota l'introduzione della possibilità di definire insiemi di pacchetti (set) da parte dell'utente.

Tanto per capire, i due set di pacchetti predefiniti di Portage sono world e system.

Paludis al contrario di Portage (se non erro, sennò fatelo presente) permette all'utente di definire dei propri set di pacchetti (che so, magari multimedia, kde-minimale, quello-che-vuoi, etc...).

Sarà possibile usare tali set in comandi come paludis --query e paludis --install, nonché nei file di configurazione use.conf, keywords.conf, licenses.conf, package_mask.conf e package_unmask.conf. Ulteriori info nella home page.

Altre nuove opzioni degne di nota sono:

- resume dei download dei pacchetti, ora specificabile con uno switch e quindi non più andando a modificare uno script.

- possibilità di disinstallare tutte le versioni di un pacchetto, con --uninstall --all-versions.

- possibilità di specificare che pacchetti in nuovi slot vengano installati solo se davvero necessario.

Per maggiori e migliori info comunque vi consiglio di leggere la documentazione.

 :Arrow:  HOME PAGE

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE

----------

## Cazzantonio

paludis mi piace sempre di più... sicuramente meglio di portage! Per ora lo sto usando solo "in prova" in quanto ho il vago sospetto di perdere la "garanzia" (ovvero l'utilizzo di bugzilla) della mia gentoo usandolo   :Rolling Eyes:   :Wink: 

----------

## Kernel78

 *Cazzantonio wrote:*   

> sicuramente meglio di portage!

 

Mi permetto di correggerti, probabilmente volevi dire: "per me sicuramente meglio di portage!", visto che io posso assicurarti che per me è ancora ben lontano da essere meglio di portage.

Certo mi stuzzicano molte features ma al momento è ancora troppo immaturo ...

----------

## jordan83

 *Cazzantonio wrote:*   

> Per ora lo sto usando solo "in prova" in quanto ho il vago sospetto di perdere la "garanzia" (ovvero l'utilizzo di bugzilla) della mia gentoo usandolo   

 

Mi sento di rassicurarti sotto questo punto di vista.

Se un pacchetto compila con Portage al 99,99999% compilerà con Paludis.

Se non compila con Portage, allo stesso modo non compilerà con Paludis.

Ciò che trovi in bugzilla con Portage varrà nella maggioranza dei casi anche con Paludis, tranne i problemi strettamente correlati a Portage.  :Wink: 

 *Kernel78 wrote:*   

> Mi permetto di correggerti, probabilmente volevi dire: "per me sicuramente meglio di portage!", visto che io posso assicurarti che per me è ancora ben lontano da essere meglio di portage. 

 

Mi piacerebbe conoscere in che cosa ritieni Portage migliore di Paludis.

Secondo me si può preferire Portage perché è più maturo (ma direi perché c'è da più tempo) e perché è ufficialmente supportato da Gentoo, nonché per motivi affettivi.  :Smile: 

Io stesso ho avuto qualche esitazione ad abbandonare emerge...  :Wink: 

In quanto a qualità di design architeturale del software, qualità e quantità di feature credo che oramai Paludis sia oggettivamente migliore di Portage da almeno un mese a questa parte.

Certo ci sono diversi angoli da sgrossare e alcune cose secondarie da implementare, tipo revdep-rebuild (per ora si usa il vecchio script modificato) o la possibilità di fare query generiche (per ora si usa ancora eix).

Non lo dico perché sono di parte, se lo usi per un po' credo lo realizzerai tu stesso.

 *Quote:*   

> 
> 
> Certo mi stuzzicano molte features ma al momento è ancora troppo immaturo ...

 

Beh in effetti non è ancora al 100% (vedi sopra) ma mi sento di rassicurare anche te. La migrazione a Paludis è nel 99,9% dei casi reversibile e di malfunzionamenti davvero non ne ho riscontrati.

Certo ci si deve abituare un attimo alle nuove opzioni e ai nuovi file di configurazione (ma direi neanche tanto nuovi, visto che sono praticamente uguali a quelli di Portage).

----------

## jordan83

Paludis 0.14.3

Queste le novità della 0.14.3:

 *Quote:*   

> - Updated zsh completion 
> 
> - The QA metadata check now handles the cached dtd properly. 
> 
> - Packages that were updated inconsistently by Portage can now be uninstalled without strange errors. 
> ...

 

Come vedete questa è solo una versione di mantenimento. Dovrebbe essere l'ultima della serie 0.14.

Spero di fare cosa gradita nel segnalare alcune cose interessanti:

- Per avere la funzionalità di elog analoga (ma forse più comoda) a quella di Portage trovate un hook in /usr/share/paludis/hooks/demos/

 che di nome fa (ma va?) elog.bash. Riporto l'intestazione:

```
# This hook makes Paludis store messages generated by an ebuild in a file.

# These stored messages are then displayed to the user after a merge. To enable

# this functionality, this script should be copied or symlinked into:

#

#     /usr/share/paludis/hooks/elog/

#     /usr/share/paludis/hooks/install_all_pre/

#     /usr/share/paludis/hooks/install_all_post/

#     /usr/share/paludis/hooks/install_fail/

#     /usr/share/paludis/hooks/uninstall_all_pre/

#     /usr/share/paludis/hooks/uninstall_all_post/

#     /usr/share/paludis/hooks/uninstall_fail/

#

# And optionally:

#

#     /usr/share/paludis/hooks/einfo/

#     /usr/share/paludis/hooks/ewarn/

#     /usr/share/paludis/hooks/eerror/

#

# You should ensure that it has execute permissions.
```

come vedete se copiate o symlinkate (neologismo...  :Wink:  ) questo hook nel primo set di cartelle attiverete la funzionalità di elog. il secondo set di cartelle "opzionali" serve invece a fare il tuning di elog e decidere quali messaggi dovranno essere raccolti e mostrati.

Notare che a differenza di Portage i messaggi vi verranno mostrati tutti alla fine.

- In /usr/share/paludis/ directory hooks e ruby trovate altre utility interessanti, tipo:

 :Arrow:  hooks/demos/new_packages.bash - fa un sommario dei nuovi pacchetti disponibili dopo un sync

 :Arrow:  hooks/demos/report.bash - per fare un paludis --report dopo un sync

 :Arrow:  ruby/demos/find_unused_distfiles.rb - script in ruby che trova quali archivi di sorgenti possono essere rimossi perché non più necesari.

Per maggiori info su dove posizionare gli hook leggete le intestazioni degli script...  :Wink: 

- Nel forum inglese (post 3840961 ) l'utente StifflerStealth ha reso disponibile a questo indirizzo il set di pacchetti kde.

Copiate il file in /etc/paludis/sets/kde3.conf e personalizzatelo, posizionando prima di ogni pacchetto:

 :Arrow:  ? se volete che il pacchetto faccia parte del set solo se già installato (altrimenti Paludis non lo installerà).

 :Arrow:  * se volete che il pacchetto faccia parte del set.

Ricordo che poi potrete usare kde3 in use.conf, etc... come fosse un pacchetto normale.

- È stato attivato un sistema per fare bug report e postare richieste di features: QUI

 :Arrow:  HOME PAGE

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE

----------

## Cazzantonio

l'unica cosa che trovo ancora un tantino "sporca" è quella di dover fare a mano i symlink per attivare determinate features   :Rolling Eyes: 

----------

## jordan83

 *Cazzantonio wrote:*   

> l'unica cosa che trovo ancora un tantino "sporca" è quella di dover fare a mano i symlink per attivare determinate features  

 

Concordo, credo che in futuro comunque sarà possibile abilitare gli hook usando eselect.

Mi sembra di aver letto da qualche parte qualcosa al riguardo.

Per ora certo bisogna adattarsi (o dare una mano a risolvere problemi come questo, se se ne ha la voglia e le capacità  :Wink:  ).

----------

## jordan83

Paludis 0.16.0

Queste le novità della 0.16.0:

 *Quote:*   

> - Enhanced DepList. Most blocks are now shown as errors in the list. Suggested dependencies are now supported. Paludis can continue resolving dependencies when encountering a masked package, and show a summary of everything that needs to be unmasked as part of the output. Post dependencies can now be installed much later on if necessary to resolve cycles. Deps in the form || ( a >=b-2 ) where b-1 is installed are handled more elegantly. Deps in the form || ( =a-1 =a-2 ) are rewritten to a single package dependency. Blockers are now handled correctly. Downgrades are now user controllable.
> 
> - New adjutrix --what-needs-keywording action, for use by arch and security teams to obtain a full list of what would need to be keyworded to mark a target to a particular keyword level.
> 
> - In repository configurations, format=portage is deprecated in favour of format=ebuild, and format=nothing is deprecated in favour of hooks.
> ...

 

In questa release le novità interessanti per noi utenti sono un paio:

1) l'opzione --dl-suggested, così definita:

```
  --dl-suggested         How to handle suggested dependencies

      show                 Display, but do not install (default)

      install              Install

      discard              Discard
```

Questa opzione mostra i pacchetti suggeriti dal sistema in relazione a un pacchetto che vogliamo installare.

2) L'opzione --dl-override-masks, così definita:

```
  --dl-override-masks    Zero or more mask kinds that can be overridden as necessary

      tilde-keyword        Keyword masks where accepting ~ would work

      unkeyworded          Keyword masks where a package is unkeyworded

      profile              Profile masks

      repository           Repository masks

      license              License masks

```

Questa opzione vi permette di far continuare a Paludis il calcolo delle dipendenze anche se incontra qualche blocco.

Questa opzione è utile ad esempio per conoscere in un solo colpo tutti i pacchetti che bisogna smascherare per installare un'applicazione ancora marcata come testing.

Supponendo che io voglia installare x11-base/xorg-x11-7.2 mi basterà dre il seguente comando per conoscere tutti i pacchetti da smascherare:

```
# paludis --dl-override-masks tilde-keyword -pi =x11-base/xorg-x11-7.2

Building target list...

Building dependency list...

These packages will be installed:

* x11-libs/libXScrnSaver-1.1.2 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-libs/libXv-1.0.3 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-libs/libXfixes-4.0.3 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-proto/damageproto-1.1.0 {:0} [! masked] <x11-libs/libXdamage-1.1::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-libs/libXdamage-1.1 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-libs/libXcursor-1.1.8 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-libs/libXcomposite-0.3.1 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-libs/libSM-1.0.2 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-apps/xmodmap-1.0.2 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-apps/xinit-1.0.3-r1 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-apps/xauth-1.0.2 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-apps/mesa-progs-6.5.2 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-libs/libdrm-2.3.0 {:0} [! masked] <media-libs/mesa-6.5.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* media-libs/mesa-6.5.2 {:0} [! masked] <x11-base/xorg-server-1.2.0::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-libs/libXfont-1.2.7 {:0} [! masked] <x11-base/xorg-server-1.2.0::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-base/xorg-server-1.2.0 {:0} [! masked] <x11-base/xorg-x11-7.2::gentoo>

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-base/xorg-x11-7.2 {:0} [! masked]

    Masked by: keyword ( ~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc ~x86 ~x86-fbsd )

* x11-libs/libXfont-1.2.7 {:0} [U 1.2.2] -debug ipv6 <x11-base/xorg-server-1.2.0::gentoo>

* x11-libs/libdrm-2.3.0 {:0} [U 2.0.2] -debug <media-libs/mesa-6.5.2::gentoo, x11-base/xorg-server-1.2.0::gentoo>

* media-libs/mesa-6.5.2 {:0} [U 6.5.1-r1] -debug doc -hardened -motif nptl -xcb% video_cards: -i810 -mach64 -mga -none -r128 radeon -s3virge -savage -sis (-sunffb) -tdfx -trident -via <virtual/glu-7.0::installed, virtual/opengl-7.0::installed, 1 more>

* x11-base/xorg-server-1.2.0 {:0} [U 1.1.1-r4] -3dfx -debug -dmx dri ipv6 -kdrive -minimal nptl sdl xorg -xprint input_devices: -acecad -aiptek -calcomp -citron -digitaledge -dmc -dynapro -elo2300 -elographics -evdev -fpit -hyperpen -jamstudio -joystick keyboard -magellan -microtouch mouse -mutouch -palmax -penmount -spaceorb -summa synaptics -tek4957 -ur98 -vmmouse -void -wacom video_cards: -apm -ark -chips -cirrus -cyrix -dummy -epson fbdev -fglrx -glint -i128 -i740 -i810 (-impact) -imstt -mach64 -mga -neomagic (-newport) -nsc -nv -nvidia -r128 radeon -rendition -s3 -s3virge -savage -siliconmotion -sis -sisusb (-sunbw2) (-suncg14) (-suncg3) (-suncg6) (-sunffb) (-sunleo) (-suntcx) -tdfx -tga -trident -tseng -v4l vesa -vga -via -vmware -voodoo <x11-base/xorg-x11-7.2::gentoo, x11-drivers/xf86-input-keyboard-1.1.0::installed, 4 more>

* x11-apps/mesa-progs-6.5.2 {:0} [U 6.5.1]  <x11-base/xorg-x11-7.2::gentoo>

* x11-apps/xauth-1.0.2 {:0} [U 1.0.1] -debug ipv6 <x11-apps/xinit-1.0.3-r1::gentoo, x11-base/xorg-x11-7.2::gentoo>

* net-misc/netkit-rsh-0.17-r7 {:0} [N] pam <x11-apps/xsm-1.0.1::gentoo>

* x11-apps/xsm-1.0.1 {:0} [N] -debug -xprint <x11-apps/xinit-1.0.3-r1::gentoo>

* x11-apps/xinit-1.0.3-r1 {:0} [U 1.0.2-r6] -debug -minimal <x11-base/xorg-x11-7.2::gentoo>

* x11-apps/xmodmap-1.0.2 {:0} [U 1.0.1] -debug <x11-base/xorg-x11-7.2::gentoo>

* x11-libs/libSM-1.0.2 {:0} [U 1.0.1] -debug ipv6 <x11-base/xorg-x11-7.2::gentoo>

* x11-libs/libXcomposite-0.3.1 {:0} [U 0.3] -debug <x11-base/xorg-x11-7.2::gentoo>

* x11-libs/libXcursor-1.1.8 {:0} [U 1.1.7] -debug <x11-base/xorg-x11-7.2::gentoo>

* x11-proto/damageproto-1.1.0 {:0} [U 1.0.3] -debug <x11-libs/libXdamage-1.1::gentoo>

* x11-libs/libXdamage-1.1 {:0} [U 1.0.3] -debug <x11-base/xorg-x11-7.2::gentoo>

* x11-libs/libXfixes-4.0.3 {:0} [U 4.0.1] -debug <x11-base/xorg-x11-7.2::gentoo>

* x11-libs/libXv-1.0.3 {:0} [U 1.0.1] -debug <x11-base/xorg-x11-7.2::gentoo>

* x11-libs/libXScrnSaver-1.1.2 {:0} [U 1.1.0] -debug <x11-base/xorg-x11-7.2::gentoo>

* x11-base/xorg-x11-7.2 {:0} [U 7.1]  <virtual/x11-7.0-r2::installed>

Total: 19 packages (2 new, 17 upgrades), 17 errors

Use flags:

* debug:           Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml .

* pam:             Adds support PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip

* xcb:             Support the X C-language Binding, a replacement for Xlib

* xprint:          Support for xprint, http://www.mozilla.org/projects/xprint/

```

L'output è un po' incasinato a causa di due fattori:

1) mancano i colori  :Wink: 

2) questo è il mio PALUDIS_OPTIONS:

```
PALUDIS_OPTIONS="--dl-reinstall if-use-changed --safe-resume --show-use-descriptions changed --show-reasons summary"
```

dove --show-use-descriptions changed serve a stampare alla fine del calcolo delle dipendenze la spiegazione di nuove (o modificate) use-flags dei pacchetti che sto installando, mentre --show-reasons summary spiega perché ciascun pacchetto viene installato (o aggiornato).

Ho lasciato queste impostazioni per darvi una idea di Paludis "on the road"  :Smile: 

Spero di aver convinto qualcuno a provarlo  :Smile: 

 :Arrow:  HOME PAGE

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE #1 (chiuso perché troppo lungo)

 :Arrow:  THREAD UFFICIALE IN INGLESE #2

 :Arrow:  PLANET PALUDIS

----------

## drizztbsd

Paludis 0.16.1

Cambiamenti:

  0.16.0 had a bug that would cause blocks to be reported incorrectly for certain virtuals. This is now fixed.

 paludis --list-* now supports a --repository-format option for restricting output.

 g++-3.4 ships with broken iterators. We now work around this.

----------

## jordan83

Paludis 0.16.2

Queste le novità della 0.16.2:

 *Quote:*   

> 
> 
> - Defaults for repository conf files can now be specified via repository_defaults.conf.
> 
> - Hooks can now determine which client is being used via the PALUDIS_CLIENT environment variable.
> ...

 

Certo non si può dire che gli sviluppatori di Paludis siano pigri   :Shocked: 

Questa è una release essenzialmente di bugfix comunque.

Segnalo che si è parlato di Paludis nella Gentoo newsletter del 22 gennaio (me ne sono accorto solo ora).

 :Arrow:  HOME PAGE

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE #1 (chiuso perché troppo lungo)

 :Arrow:  THREAD UFFICIALE IN INGLESE #2

 :Arrow:  PLANET PALUDIS

----------

## jordan83

Paludis 0.18.1

Sono uscite due nuove versioni, come al solito abbastanza ravvicinate... 1 giorno!   :Smile: 

Queste le novità della 0.18.0:

 *Quote:*   

> 
> 
> - Huge code cleanup. If your compiler does not implement tr1, you will now need boost installed. 
> 
> - Much faster adjutrix --what-needs-keywording when the system set includes blocks. 
> ...

 

Queste le novità della 0.18.1:

 *Quote:*   

> 
> 
> - use.conf etc now automatically includes use.conf.d/*.conf. 
> 
> - New configuration key for ebuild repositories, master_repository. If set, the specified repository will be used as a 'master' for profiles/, eclasses, PORTDIR etc. 
> ...

 

Novità assolutamente importanti:

- gestione completa dei set: ora è possibile installarli (con scrittura del set nel file world) e disinstallarli (cosa che fino alla versione 0.16.2 non era disponibile).

- possibilità di definire use.conf, keywords.conf, etc... come directory come si faceva in Portage (cloc3 dovrebbe esserne felice..  :Smile:  ). Le directory si devono chiamare use.conf.d, keywords.conf.d, etc... Consultate il sito di Paludis per maggiori info. Lo script portage2paludis è stato migliorato ed è a sua volta in grado di importare i file di configurazione specificati in directory.

- inquisitio, il nuovo tool per fare ricerche generiche. Per la verità al momento è più lento di una tartaruga, vi consiglio di provarlo in futuro...  :Smile: 

Ho notato che nell'svn è disponibile anche uno script per effettuare il revdep-rebuild. Per ora non è stato ancora rilasciato ufficialmente con il pacchetto.

 :Arrow:  HOME PAGE

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE #1 (chiuso perché troppo lungo)

 :Arrow:  THREAD UFFICIALE IN INGLESE #2

 :Arrow:  PLANET PALUDIS

----------

## Kernel78

Ok, ammetto che l'idea inizia a solleticarmi (soprattutto perchè adoro ruby) ma ci sono ancora cose che mi rendono cauto ...

 *jordan83 wrote:*   

> Sono uscite due nuove versioni, come al solito abbastanza ravvicinate... 1 giorno!  
> 
> 

 

Personalmente non vedo come positive uscite così frequenti:

- o si sono dimenticati qualcosa e l'hanno aggiunta il giorno dopo (e allora mi chiedo cos'altro potrebbero dimenticarsi)

- o si sono accorti di alcuni bug e li hanno risolti il giorno dopo (e allora potevano fare le cose con più calma e testare meglio)

- o hanno aggiunto nuove funzioni (e allora hanno avuto poco tempo per testarle)

Cmq cerco di girarlo non riesco a essere positivamente colpito da versioni così ravvicinate, sarà anche un segno che lavorano alacremente allo sviluppo ma mi da troppo l'impressione di un metodo di sviluppo troppo poco curato (ovviamente per i miei standard).

Quando inizierà ad apparire una versione stabile allora inizierò a prendere in seria considerazione l'idea di provarlo  :Wink: 

----------

## drizztbsd

Se aspetti che esca una versione marcata stable (quindi non tilde) devi aspettare moooooooooooolto tempo.

Se vuoi una versione che funzioni puoi sempre usare la 0.18.1 (almeno che tu non abbia mips)  :Cool: 

----------

## Kernel78

 *Drizzt Do` Urden wrote:*   

> Se aspetti che esca una versione marcata stable (quindi non tilde) devi aspettare moooooooooooolto tempo.
> 
> Se vuoi una versione che funzioni puoi sempre usare la 0.18.1 (almeno che tu non abbia mips) 

 

Il fatto è che sono decisamente restio ad usare pacchetti non stabili, soprattutto se si tratta di pacchetti che hanno una discreta importanza per il sistema.

Mi sto interessando a questo progetto perché le novità mi attirano ma al momento non ho nessuna ragione pratica che mi spinga ad allontanarmi dall'attuale e stabile situazione per testarne una che ritengo ancora immatura (e il fatto che non è ancora stabile significa che non sono l'unico a pensarla così), mi sembra un bel giocattolino e di sicuro potrebbero esserci molti utenti pronti a giurare che l'hanno usato e stressato senza il minimo problema ma la mia idea non cambia...

Molte release in poco tempo a mio parere indicano un pessimo modello di sviluppo e il fatto che in molti siano stati fortunati a non aver problemi non mi sembra un riscontro abbastanza oggettivo a dimostrazione della sua stabilità.

----------

## drizztbsd

beh il fatto che un pacchetto sia ~ o non ~ non è significativo (molto spesso i pacchetti ~ compilano e quello non ~ no)

paludis ha una cifra di unit tests 

```
FEATURES=test emerge paludis
```

 che testano quasi completamente la funzionalità del codice (portage non ce li ha)

poi se te vuoi rimanere con un package mangler lento come la fame e con un codice incomprensibile 

```
drizzt@janeway ~ % wc -l `which emerge`

5279 /usr/bin/emerge
```

 è un problema tuo  :Razz: 

----------

## jordan83

 *Kernel78 wrote:*   

> 
> 
> Molte release in poco tempo a mio parere indicano un pessimo modello di sviluppo e il fatto che in molti siano stati fortunati a non aver problemi non mi sembra un riscontro abbastanza oggettivo a dimostrazione della sua stabilità.

 

Basare la bontà di un progetto solo sui tempi di sviluppo non mi pare una buona filosofia.

E per quanto riguarda il riscontro oggettivo... nei forums leggo di moltissima gente costretta a prodursi script per coprire le mancanze di Portage sebbene questo dovrebbe essere un tool "maturo".

Il fatto che sia sviluppato lentamente in questo caso è dovuto al fatto che è difficile da modificare.

Per fare un esempio ricordo di una cosiddetta feature confcache che venne introdotta in stable per essere rimossa in fretta e furia un paio di settimane dopo perché portava maree di problemi...  :Wink: 

Non mi pare che in questo caso l'aver aspettato mesi abbia aiutato granché.

Se vuoi la mia opinione questi tempi ristretti sono permessi proprio dalla qualità del lavoro di ingegnerizzazione fatto inizialmente nonché dall'utilizzo di strumenti adatti (vedi ad esempio libebt e libwrapiter).

Senza mettere in secondo piano le qualità di chi ci lavora, che ricordo sono od erano Gentoo developers.

In 8 mesi Paludis supporta features che Portage non ha ancora permesso in 3-4 anni e questo in gran parte per il fatto che Portage non è stato strutturato bene (convinzione di molti, non solo mia).

----------

## Kernel78

 *Drizzt Do` Urden wrote:*   

> beh il fatto che un pacchetto sia ~ o non ~ non è significativo (molto spesso i pacchetti ~ compilano e quello non ~ no)
> 
> 

 

beh, può non essere risolutivo ma significativo lo è di sicuro a meno che tutti quelli che lo provano ~ non segnalano i bug che riscontrano quando diventa non ~ i bug segnalati dovrebbero essere risolti.

 *Quote:*   

> 
> 
> paludis ha una cifra di unit tests 
> 
> ```
> ...

 

Se tu vuoi usare un prodotto sviluppato secondo un modello quantomeno inefficiente con tutte le problematiche che ne conseguono è un problema tuo  :Razz:  se poi lo vuoi usare per testarlo e trovare bug per aiutare lo sviluppo allora ritengo il tuo comportamento encomiabile ma se lo usi in ambienti operativi allora mi sorgono seri dubbi sul tuo futuro professionale ...

----------

## jordan83

 *Kernel78 wrote:*   

> 
> 
> Se tu vuoi usare un prodotto sviluppato secondo un modello quantomeno inefficiente con tutte le problematiche che ne conseguono

 

Puoi spiegare perché ritieni questo modello di sviluppo inefficiente?

----------

## Kernel78

 *jordan83 wrote:*   

>  *Kernel78 wrote:*   
> 
> Se tu vuoi usare un prodotto sviluppato secondo un modello quantomeno inefficiente con tutte le problematiche che ne conseguono 
> 
> Puoi spiegare perché ritieni questo modello di sviluppo inefficiente?

 

L'ho già fatto quando ho scritto:

 *Quote:*   

> Personalmente non vedo come positive uscite così frequenti:
> 
> - o si sono dimenticati qualcosa e l'hanno aggiunta il giorno dopo (e allora mi chiedo cos'altro potrebbero dimenticarsi)
> 
> - o si sono accorti di alcuni bug e li hanno risolti il giorno dopo (e allora potevano fare le cose con più calma e testare meglio)
> ...

 

----------

## jordan83

 *Kernel78 wrote:*   

> 
> 
> - o si sono dimenticati qualcosa e l'hanno aggiunta il giorno dopo (e allora mi chiedo cos'altro potrebbero dimenticarsi)
> 
> 

 

Questo no ^_^

 *Kernel78 wrote:*   

> 
> 
> - o si sono accorti di alcuni bug e li hanno risolti il giorno dopo (e allora potevano fare le cose con più calma e testare meglio)
> 
> 

 

Questo mi pare sia successo 1 volta. E comunque risolvere i bug in giornata non mi pare così inefficiente ^_^

 *Kernel78 wrote:*   

> 
> 
> - o hanno aggiunto nuove funzioni (e allora hanno avuto poco tempo per testarle)
> 
> 

 

Questo sì ma d'altronde, come detto più volte, Paludis viene sviluppato velocemente.

Gran parte delle funzionalità si basa su codice (gestion repository, dipendenze...) testato da un po'. Certo non è ancora 1.x  :Wink: 

Assicurazioni totali non esistono, vedi ad esempio (ricerca di 1 minuto):

- Post 1

- Post 2

- Post 3

----------

## drizztbsd

 *Kernel78 wrote:*   

> Se tu vuoi usare un prodotto sviluppato secondo un modello quantomeno inefficiente con tutte le problematiche che ne conseguono è un problema tuo  se poi lo vuoi usare per testarlo e trovare bug per aiutare lo sviluppo allora ritengo il tuo comportamento encomiabile ma se lo usi in ambienti operativi allora mi sorgono seri dubbi sul tuo futuro professionale ...

 

Entrambe, http://paludis.pioto.org/authors.html Timothy Redaelli sono io e non preoccuparti del mio futuro professionale dato che ho paludis su un server di produzione (un server sip) e non ho mai avuto nessun problema   :Cool: 

----------

## Kernel78

 *Drizzt Do` Urden wrote:*   

>  *Kernel78 wrote:*   Se tu vuoi usare un prodotto sviluppato secondo un modello quantomeno inefficiente con tutte le problematiche che ne conseguono è un problema tuo  se poi lo vuoi usare per testarlo e trovare bug per aiutare lo sviluppo allora ritengo il tuo comportamento encomiabile ma se lo usi in ambienti operativi allora mi sorgono seri dubbi sul tuo futuro professionale ... 
> 
> Entrambe, http://paludis.pioto.org/authors.html Timothy Redaelli sono io e non preoccuparti del mio futuro professionale dato che ho paludis su un server di produzione (un server sip) e non ho mai avuto nessun problema  

 

Ho visto anche gente mettere windows su server di produzione e gli amministratori giurare di non aver mai avuto problemi ma questo non significa che sia stabile ...

Tu lo ritieni adatto alle tue esigenze ? Buon per te.

A me sembra sempre più un progetto interessante, sulla carta, ma al momento, come ho già detto, non mi ispira sufficientemente fiducia ne mi trovo male con portage da dover cercare delle alternative.

Continuo a seguire questa discussione e ogni tanto vado sul sito a vedere quali progressi ha fatto ma al momento non prendo nemmeno in considerazione l'idea di installarlo anche se mi piacere trovare una macchina e del tempo per provarlo.

Purtroppo al momento non ho una macchina disponibile per fare delle prove e con una moglie gravida che mi spedisce a ricercare ingredienti mai sentiti per soddisfare i suoi desideri culinari ho decisamente poco tempo a disposizione per qualsiasi tipo di prova.

----------

## Scen

 *Kernel78 wrote:*   

> Purtroppo al momento non ho una macchina disponibile per fare delle prove e con una moglie gravida che mi spedisce a ricercare ingredienti mai sentiti per soddisfare i suoi desideri culinari ho decisamente poco tempo a disposizione per qualsiasi tipo di prova.

 

 :Very Happy: 

....

Ho installato anche io Paludis sulle due mie macchine casalinghe (1 x86 e 1 AMD64), purtroppo non ho proseguito oltre

```

emerge paludis

```

quando avrò un pò di tempo mi metto sotto a testarlo   :Cool: 

Domandina veloce: Portage e Paludis possono funzionare "parallelamente" o l'utilizzo di uno esclude l'altro?

----------

## jordan83

 *Scen wrote:*   

> 
> 
> Domandina veloce: Portage e Paludis possono funzionare "parallelamente" o l'utilizzo di uno esclude l'altro?

 

No, puoi far convivere entrambi.

L'unica feature che rompe la compatibilità con Portage sono i set, da quel che mi risulta.

Se installi un set con Paludis nel file world ne viene memorizzato il nome e Portage ovviamente non è in grado di riconoscerlo.

Io ad esempio ho personalizzato kde con un set kde3 e ora nel file world è presente tale voce che portage non saprebbe gestire.

----------

## cloc3

 *jordan83 wrote:*   

> 
> 
> Io ad esempio ho personalizzato kde con un set kde3 

 

funziona come mettere un meta-pacchetto personalizzato in portage overlay?

----------

## jordan83

 *cloc3 wrote:*   

> 
> 
> funziona come mettere un meta-pacchetto personalizzato in portage overlay?

 

No, non è proprio la stessa cosa.

Supponiamo tu definisca il seguente set mioSet in /etc/paludis/sets/mioSet.conf

```

* pacchetto_1

* pacchetto_2

? pacchetto_3

```

Quando dai

```
paludis -i mioSet
```

verranno installati pacchetto_1 e pacchetto_2.

Il pacchetto_3 verrà considerato parte del set solo se già presente nel sistema, come una sorta di dipendenza "debole".

Una volta definito il set lo puoi usare negli altri file di configurazione, tipo use.conf o keywords.conf.

Se ad esempio io volessi fare l'upgrade di Kde 3 dal 3.5.5 al 3.5.6 dovrei aggiungere in keywords.conf solo questa riga:

```
kde3 ~x86
```

 :Wink: 

Se usi solo gli asterischi nella definizione del set è praticamente come avere un metapacchetto.

----------

## Apetrini

Non ho ancora provato Paludis, non penso di provarlo, almeno per ora. Mi ritengo una persona che sperimenta molto(ho il sistema in x86, moltissimi pacchetti in ~x86, tanti hard-masked e una trentina di missing-keywords), ma sinceramente non me la sono sentita di provare Paludis.

Il progetto sembra promettere bene e ciò mi rende molto contento, ma il fatto che a molti funziona tutto non è un motivo valido(secondo me) per provarlo.

Magari con le operazioni normali funge, ma chissà se facendo porcate o cose al limite funziona. Magari molte porcate che  il portage tollera, Paludis no.

Mi dispiace ma penso che aspetterò che diventi parte ufficiale di gentoo. Magari tra un paio di anni.

E poi....secondo me....il portage funziona molto bene...

----------

## jordan83

 *Apetrini wrote:*   

> Non ho ancora provato Paludis, non penso di provarlo, almeno per ora. Mi ritengo una persona che sperimenta molto(ho il sistema in x86, moltissimi pacchetti in ~x86, tanti hard-masked e una trentina di missing-keywords), ma sinceramente non me la sono sentita di provare Paludis.

 

ehmbé... decisamente Paludis potrebbe rendere il tuo sistema instabile...  :Mr. Green:   :Very Happy: 

 *Apetrini wrote:*   

> 
> 
> Il progetto sembra promettere bene e ciò mi rende molto contento, ma il fatto che a molti funziona tutto non è un motivo valido(secondo me) per provarlo.

 

Allora non provarlo ^_^

 *Apetrini wrote:*   

> 
> 
> Magari con le operazioni normali funge, ma chissà se facendo porcate o cose al limite funziona. Magari molte porcate che  il portage tollera, Paludis no.

 

Alcuni punti su cui riflettere:

- Portage è poco rigoroso. Per fare un esempio: nel thread ufficiale di Paludis un utente lamentava il fatto che un ebuild "fatto in casa" (vedi il post) non compilava con Paludis (si bloccava stampando alcuni errori) mentre Portage installava il pacchetto senza problemi; dopo alcune indagini si è scoperto che l'ebuild in questione conteneva errori piuttosto grossolani e mentre Paludis segnalava la cosa, Portage redirigeva tutto a /dev/null, fregandosene   :Rolling Eyes: 

Magari non è bene che Portage tolleri le "porcate"... ^_^

Leggo così spesso di utenti che si lamentano del fatto che la qualità di Gentoo sta scadendo... Magari un motivo c'è  :Wink: 

Mai provato ad attivare la funzione test delle feature? In Paludis è abilitata di default... Io ho dovuto disabilitarla perché altrimenti un sacco di pacchetti stabili non compilerebbero a causa di "porcate" in essi presenti.

- Portage non è scalabile: gestione overlay, prestazioni, ereditarietà dei profili, dipendenze delle use-flags e un'altra tonnellata di funzionalità di cui si è stradiscusso in lungo e in largo, in Portage mancano o sono carenti. Poi che ci si faccia andare bene tutto per "amore" di Gentoo e Portage è un altro discorso.  :Wink: 

- altri "N" motivi che mi accorgo di non aver voglia di ripetere per la 20ma volta.  :Wink: 

 *Apetrini wrote:*   

> 
> 
> Mi dispiace ma penso che aspetterò che diventi parte ufficiale di gentoo. Magari tra un paio di anni.
> 
> 

 

Più che legittimo.

Certo, ripeto, non credo sarebbe Paludis a rendere instabile il tuo sistema...

Se mi permetti mi pare un controsenso che tu dica che non vuoi provare Paludis perché potrebbe essere instabile quando poi vuoi fare "porcate" sul tuo sistema. Hai N condizioni di rischio e ti lamenti della N+1 (probabilmente la meno pericolosa, visti i feedback avuti finora)  :Neutral: 

 *Apetrini wrote:*   

> 
> 
> E poi....secondo me....il portage funziona molto bene...

 

La vita è fatta di gusti e di scelte.

----------

## Cazzantonio

imho l'unico problema è dover imparare alcuni comandi diversi...   :Rolling Eyes:  Non he siano poi molti...

----------

## Kernel78

 *Cazzantonio wrote:*   

> imho l'unico problema è dover imparare alcuni comandi diversi...   Non he siano poi molti...

 

Hai visto qui ? tra comandi e opzioni la lista non mi sembra particolarmente breve  :Rolling Eyes: 

Che poi uno possa limitarsi a uno o due e ignorare gli altri (come già avviene con emerge dove la maggior parte della gente non conosce -t, molti non conoscono -N e via dicendo) non significa che siano pochi.

----------

## Cazzantonio

Devi sempre fare polemica?

----------

## Kernel78

 *Cazzantonio wrote:*   

> Devi sempre fare polemica?

 

Solo per mettere al suo posto chi fa il saccente  :Wink: 

1)hai iniziato tu a far rotear gli occhi sostenendo una cosa palesemente inesatta.

2)se hai problemi con me non trovo corretto che posti sul forum, mandami un messaggio e ci chiariamo in privato.

----------

## jordan83

Paludis 0.20.1

Segnalazione un po' tardiva...  :Razz: 

Queste le novità della 0.20.0:

 *Quote:*   

> 
> 
> - Merging is now handled by the destination repository. The new merger code does a two pass merge to catch most errors before the filesystem is modified. New merger hooks allow for much more flexibility. 
> 
> - Hooks returning non-zero will now usually cause an abort rather than a warning. 
> ...

 

Queste le novità della 0.20.1:

 *Quote:*   

> 
> 
> - Bug fix: variables from saved environments would sometimes not be exported to helper programs due to a 'feature' of declare -x in bash.
> 
> 

 

Due release in tono minore (la seconda è solo un bugfix, come potete notare).

Per chi fosse interessato, lo sviluppatore principale, Ciaran McCreesh, ha postato sul suo blog una riflessione su quanto fatto finora in Paludis e qualche goal per gli sviluppi futuri.  :Wink: 

 :Arrow:  HOME PAGE

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE #1 (chiuso perché troppo lungo)

 :Arrow:  THREAD UFFICIALE IN INGLESE #2

 :Arrow:  PLANET PALUDIS

----------

## Cazzantonio

Mi chiedo: a quando qualche stage di installazione (1, 2 o 3... non importa) con paludis al posto di portage? Aspetteranno la 1.0? 

Se procede come sta procedendo ora per la 1.0 potrebbe addirittura essere diventato il gestore di pacchetti ufficiale   :Wink: 

----------

## jordan83

 *Cazzantonio wrote:*   

> Mi chiedo: a quando qualche stage di installazione (1, 2 o 3... non importa) con paludis al posto di portage? Aspetteranno la 1.0? 
> 
> 

 

Infatti, me lo chiedo pure io.

Paludis oramai è pronto alla "promozione" da un po'. Almeno in qualche stage/profilo "testing".

L'unica feature di Portage che manca in Paludis è la generazione di pacchetti binari, che comunque è prossima all'arrivo.

Per il resto direi che c'è tutto (e mooooooooolto di più  :Smile:  ).

Ora c'è anche lo script per il revdep-rebuild (check_linkage.rb), il corrispondente di eclean (find_unused_distfiles.rb), c'è l'etc-config (etc-paludis) e ho visto che stanno scrivendo anche uno script (config-decruft) per pulire i file di configurazione (use inutili, pacchetti smascherati per niente, etc...).

L'unica cosa che ancora mi trattiene dal rimuovere Portage è il voler testare un po' meglio questi script, in modo da essere sicuro che tutto funzioni alla perfezione.

Personalmente, se tutto continua così, non vedo alcuna concreta possibilità per me di tornare indietro a Portage, per cui mi auguro che Paludis venga al più presto impostato come gestore ufficiale in qualche stage  :Wink: 

----------

## .:deadhead:.

Con l'atteggiamento costruttivo che ciaranm ha avuto e continua ad avere e con il suo comportamento edificante ha fatto terra bruciata attorno a sè.

Non mi stupirei affatto quindi se paludis non venisse mai integrato in gentoo, specie ora che è stato cacciato come devel.

Inoltre non credo che in molti sarebbero disposti ad imparare un nuovo set di comandi per la gestione dei pacchetti. e ciaranm non ha assolutamente intenzione di utilizzare i medesimi parametri di portage. Alla faccia della transizione facile.

----------

## jordan83

 *.:deadhead:. wrote:*   

> Con l'atteggiamento costruttivo che ciaranm ha avuto e continua ad avere e con il suo comportamento edificante ha fatto terra bruciata attorno a sè.

 

Eh infatti.

Non è un gran diplomatico, anzi.

 *.:deadhead:. wrote:*   

> 
> 
> Non mi stupirei affatto quindi se paludis non venisse mai integrato in gentoo, specie ora che è stato cacciato come devel.

 

Beh credo lo abbiano cacciato da diversi contesti, non solo come developer...  :Razz: 

Certo se Paludis venisse messo da parte si farebbe un gran passo indietro, almeno secondo me.

Che uno sia o meno d'accordo con Ciaran resta il fatto che Portage ha bisogno di una bella sistemata.  :Neutral: 

Se si giudicasse l'opera dalla persona... nemmeno Torvalds è un tipo così tranquillo e diplomatico.

Per fare un esempio, non mi pare sia stato così "diplomatico" nel fornire le sue idee su Gnome.

Nonostante tutto Linux esiste per merito suo, e funziona bene anche (ma qui non solo grazie a lui)  :Wink: 

Pure a me spesso sta sulle scatole il modo di fare di Ciaran ma il tool che ha scritto ha ottime qualità.

Qualche idea buona ce l'ha anche lui, sebbene sia bravo a farsi odiare...

 *.:deadhead:. wrote:*   

> 
> 
> Inoltre non credo che in molti sarebbero disposti ad imparare un nuovo set di comandi per la gestione dei pacchetti. e ciaranm non ha assolutamente intenzione di utilizzare i medesimi parametri di portage. Alla faccia della transizione facile.

 

Qua non sono d'accordo, visto che la "fatica" che si dovrebbe fare porterebbe via al max 1 ora (e già 1 ora è una eternità).

Se davvero questo fosse lo scoglio "insormontabile" allora stiamo freschi....   :Rolling Eyes: 

Compiliamo il kernel e non sappiamo usare 4 switch?

----------

## Kernel78

 *jordan83 wrote:*   

>  *.:deadhead:. wrote:*   
> 
> Inoltre non credo che in molti sarebbero disposti ad imparare un nuovo set di comandi per la gestione dei pacchetti. e ciaranm non ha assolutamente intenzione di utilizzare i medesimi parametri di portage. Alla faccia della transizione facile. 
> 
> Qua non sono d'accordo, visto che la "fatica" che si dovrebbe fare porterebbe via al max 1 ora (e già 1 ora è una eternità).
> ...

 

beh, c'è molta gente che ancora posta per problemi con le opzioni di emerge e quelle esistono da molto più tempo, quindi direi di si; c'è gente che ancora non sa usare "4" switch ...

Un'altra curiosità (sperando di non andare OT): come mai auspichi un profilo con paludis come gestore di default ?

Ti cambierebbe qualcosa o sarebbe solo per vedere riconosciuta a questo strumento una ufficialità che fino ad ora gli manca ?

P.S. forse riesco a riesumare un portatile dell'anteguerra punica per provarci sopra paludis, tutto sta nel tempo che riesco a ritagliarmi  :Wink: 

In questo modo spero di riuscire a contribuire in maniera più costruttiva e con una maggior cognizione di causa.

----------

## jordan83

 *Kernel78 wrote:*   

> 
> 
> beh, c'è molta gente che ancora posta per problemi con le opzioni di emerge e quelle esistono da molto più tempo, quindi direi di si; c'è gente che ancora non sa usare "4" switch ...
> 
> 

 

Vabbé, ci sarà sempre chi incontra difficoltà con i comandi. Anche se non esistessero switch e bastasse lanciare il tool senza alcun argomento...   :Smile: 

 *Kernel78 wrote:*   

> 
> 
> Un'altra curiosità (sperando di non andare OT): come mai auspichi un profilo con paludis come gestore di default ?
> 
> Ti cambierebbe qualcosa o sarebbe solo per vedere riconosciuta a questo strumento una ufficialità che fino ad ora gli manca ?
> ...

 

Credo più che altro per l'ufficialità.

Rendere Paludis ufficialmente supportato aiuterebbe ad ampliare la base utenti e di conseguenza lo sviluppo risulterebbe più agevole (con evidenti benefici per gli utenti  :Wink:  )

In più rendere Paludis un po' più ufficiale aumenterebbe le possibilità di un suo reale utilizzo futuro.

A me sembrerebbe ovvio vedere in Paludis il successore di Portage, tuttavia devo riconoscere che purtroppo lo sviluppatore principale (Ciaran) non sta aiutando il suo progetto in tal senso...  :Rolling Eyes: 

Ho la strana convinzione che se ci fosse qualcun altro a capo del progetto a quest'ora avremmo già profili "stable" per paludis...  :Razz: 

 *Kernel78 wrote:*   

> 
> 
> P.S. forse riesco a riesumare un portatile dell'anteguerra punica per provarci sopra paludis, tutto sta nel tempo che riesco a ritagliarmi 
> 
> In questo modo spero di riuscire a contribuire in maniera più costruttiva e con una maggior cognizione di causa.

 

Ottimo.

Qualche parere in più aiuterà tutti a farsi un'idea più chiara dei pregi e dei difetti del tool  :Wink: 

----------

## djinnZ

Ho dato un primo sguardo a paludis (anche al codice) e non è che mi abbia fatto una buona impressione, risolve il problema della dipendenza da python ma continuerei a preferire un approccio più "old unix" e lineare per un applicativo così critico (quindi bash+eseguibili minimi, con minime dipendenze di libreria) e di certo non trovo apprezzabile, al di fuori del nome del progetto, cambiare comandi ed opzioni.

Forse l'unica cosa che riesco ad apprezzare in apt, nonostante la mia avversione verso debian (ma più che altro verso le distribuzioni binarie) e che bene o male è rimasto sempre uguale.

Visti poi i problemi legati al suo "genitore"... resto interdetto.

Ma visto che per il momento è l'unica alternativa seria e portage inizia a perdere colpi ci si deve accontentare e continuerò a provarlo sul disco di test.

Poi resta il problema dei diritti ma questa è una discussione che qui non mi pare indicata.

----------

## Cazzantonio

 *.:deadhead:. wrote:*   

> Con l'atteggiamento costruttivo che ciaranm ha avuto e continua ad avere e con il suo comportamento edificante ha fatto terra bruciata attorno a sè.
> 
> Non mi stupirei affatto quindi se paludis non venisse mai integrato in gentoo, specie ora che è stato cacciato come devel.

 

Scusate il tono da ciana di quartiere... ma cosa ha fatto questo ciaranm?   :Shocked: 

Non per farmi gli affari di costui ma se viene tirato in ballo sono curioso   :Smile: 

----------

## djinnZ

vedi qui poi c'è il fatto che non è chiaro se paludis potrebbe essere "intestato" alla fondazione o meno, se non ho capito male.

----------

## jordan83

Paludis 0.20.2

Queste le novità della 0.20.2:

 *Quote:*   

> 
> 
> - Various bug fixes, most notably ncurses should now be upgradable.
> 
> 

 

Bugfixes  :Wink: 

 :Arrow:  HOME PAGE

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE #1 (chiuso perché troppo lungo)

 :Arrow:  THREAD UFFICIALE IN INGLESE #2

 :Arrow:  PLANET PALUDIS

----------

## Kernel78

Non vorrei sembrare poco costruttivo ma non riesco a capire l'utilità di postare il changelog ogni volta ...

Se tutti noi aprissimo discussioni simili per ogni pacchetto sarebbe un bel casino ...

Capirei se riportassi le grosse migliorie e innovazioni ma così mi sembra un po' eccessivo  :Wink: 

Visto che sono qui ne approfitto per farti anche una domanda in veste di esperto Paludis.

Mi annoio a seguire sulla gwn i pacchetti che verranno rimossi e cercare se ne ho alcuni installati e rimuoverli (per non avere spazzatura sulla macchina), c'è un modo in cui paludis possa prendersene carico per me ?

Spero di essermi spiegato ...

Grazie.

----------

## jordan83

 *Kernel78 wrote:*   

> Non vorrei sembrare poco costruttivo ma non riesco a capire l'utilità di postare il changelog ogni volta ...
> 
> Se tutti noi aprissimo discussioni simili per ogni pacchetto sarebbe un bel casino ...
> 
> Capirei se riportassi le grosse migliorie e innovazioni ma così mi sembra un po' eccessivo 
> ...

 

Eeh forse hai ragione. Era solo per completezza, visto che ho riportato tutte le uscite dall 0.8 (mi pare).  :Razz: 

Comunque dalla prossima volta posterò solo in caso di migliorie interessanti.

 *Kernel78 wrote:*   

> 
> 
> Mi annoio a seguire sulla gwn i pacchetti che verranno rimossi e cercare se ne ho alcuni installati e rimuoverli (per non avere spazzatura sulla macchina), c'è un modo in cui paludis possa prendersene carico per me ?
> 
> Spero di essermi spiegato ...
> ...

 

Se la funzionalità che chiedi è già presente, la trovi al 99% nello switch --report.

Comunque non son sicuro che --report sia già così evoluto...  :Neutral: 

----------

## klaimath

Spero di non andare OT nel qual caso ditemelo per cortesia.

Se non ho capito male la discussione stiamo parlando di un gestore di pacchetti "alternativo" a portage, e fin qua non ci sarebbe niente di male, ma che in parte è scopiazzato pari pari da portage con solo alcuni nomi cambiati.

Ammetto di non aver provato Paludis quindi la mia cognizione è solo quella che ho letto in questo post e sul sito ufficiale del progetto ma la domanda fondamentale è la seguente:

Sul serio c'è bisogno di un nuovo gestore di pacchetti ?

A parer mio la risposta non può essere che NO non c'è bisogno. Ci sarebbe semmai bisogno di dare una bella sistemata a quello che già abbiamo e non tanto per non dover imparare qualcosa di nuovo, sono convinto che alla fine si tratterebbe di un'oretta di studio, ma perchè quel che c'è, sempre imho, basta e cresce ma potrebbe essere migliorato.

Prendo ad esempio la gestione delle dipendenze. 

E' ovvio che se il pacchetto X richiede i pacchetti Y e Z questi devono essere compilati ma se voglio rimuovere X i pacchetti Y e Z se ne stanno belli belli sul sistema e magari non servono a un tubo. Quindi per quale motivo tenerli installati ? Non sarebbe più facile rimuoverli ?

Forse una funzione di portage capace di fare questo, o un check delle dipendenze installate con il pacchetto X per vedere se servono ancora (es: se sono usate da altri pacchetti installati dopo X) non sarebbe male. 

In fin dei conti un packet manager dovrebbe fornire al utente un'interfaccia per:

- Installare i pacchetti e le loro dipendenze

- Rimuovere i pacchetti e le loro dipendenze se queste non servono ad altri pacchetti

- Eventualmente ricompilare le dipendenze con (se si sta installando un pacchetto che le richiede) il supporto per un dato pacchetto o rimuovendo tale supporto in caso di disinstallazione.

Certo Portate fa molto di più ma le operazioni base a parer mio dovrebbero essere queste e sinceramente non le vedo (forse ho studiato male) e ne sento la mancanza.

Ribadisco tutto rigorosamente IMHO.

Cya

Klaimath

----------

## lavish

@Klaimath:

benche' io non la pensi in modo molto diverso da te, questo post non e' molto adatto al thread visto che si stava discutendo di Paludis dal punto di vista puramente funzionale e tecnico. Se vuoi posso splittare il post e aprire una nuova discussione del titolo "Paludis vs. World" (  :Razz:  ), ma penso che il thread degenererebbe rapidamente in un flame   :Confused: 

Altra cosa:

 *Quote:*   

> Prendo ad esempio la gestione delle dipendenze.
> 
> E' ovvio che se il pacchetto X richiede i pacchetti Y e Z questi devono essere compilati ma se voglio rimuovere X i pacchetti Y e Z se ne stanno belli belli sul sistema e magari non servono a un tubo. Quindi per quale motivo tenerli installati ? Non sarebbe più facile rimuoverli ?
> 
> Forse una funzione di portage capace di fare questo, o un check delle dipendenze installate con il pacchetto X per vedere se servono ancora (es: se sono usate da altri pacchetti installati dopo X) non sarebbe male. 

 

 Da man emerge (e' abbastanza recente questa innovazione):

```
       --with-bdeps < y | n >

              In  dependency  calculations,  pull  in build time dependencies

              that are not strictly required.    This  defaults  to  'n'  for

              installation  actions  and 'y' for the --depclean action.  This

              setting can be added to EMERGE_DEFAULT_OPTS (see  make.conf(5))

              and later overridden via the command line.
```

Ciao!

----------

## klaimath

 *lavish wrote:*   

> @Klaimath:
> 
> benche' io non la pensi in modo molto diverso da te, questo post non e' molto adatto al thread visto che si stava discutendo di Paludis dal punto di vista puramente funzionale e tecnico. Se vuoi posso splittare il post e aprire una nuova discussione del titolo "Paludis vs. World" (  ), ma penso che il thread degenererebbe rapidamente in un flame  :
> 
> Ciao!

 

Niente split non volevo aprire una polemica ne andare OT ma solo sottolineare una cosa che secondo me manca.

----------

## jordan83

 *klaimath wrote:*   

> 
> 
> Se non ho capito male la discussione stiamo parlando di un gestore di pacchetti "alternativo" a portage, e fin qua non ci sarebbe niente di male, ma che in parte è scopiazzato pari pari da portage con solo alcuni nomi cambiati.
> 
> 

 

In realtà Paludis cerca di essere compatibile con Portage, il che è ben diverso  :Wink: 

Ci sono molte cose che potrebbero essere fatte in modo diverso (ad esempio il formato VDB, che è un collo di bottiglia piuttosto stretto) ma al momento non è possibile perché altrimenti si otterrebbe un packet manager incompatibile con Gentoo, cosa che porterebbe il progetto a morire in due settimane  :Razz: 

Per quanto riguarda la scopiazzatura... Credo tu abbia interpretato piuttosto erroneamente la situazione.

Paludis offre quello che offre Portage (meno il supporto per la generazione di pacchetti binari, in arrivo nelle prossime versioni) più un insieme più che considerevole di nuove funzionalità, di cui puoi avere un'idea qui:

- 1

- 2

E questo alla versione 0.20.2  :Wink: 

 *klaimath wrote:*   

> 
> 
> Ammetto di non aver provato Paludis quindi la mia cognizione è solo quella che ho letto in questo post e sul sito ufficiale del progetto ma la domanda fondamentale è la seguente:
> 
> Sul serio c'è bisogno di un nuovo gestore di pacchetti ?
> ...

 

Questa domanda ha N risposte. Ognuna di esse è giusta e al contempo sbagliata.

Molti utenti risponderebbeo sì, molti no. Dipende dai punti di vista, come al solito  :Smile: 

Spesso mi chiedo a cosa servano 130+ distribuzioni. Fino a un anno fa mi chiedevo che potesse avere di buono Gentoo.

Ora la uso  :Wink: 

A volte non si sente la necessità di qualcosa finché non la si è provata e non se ne sono viste le potenzialità.

 *klaimath wrote:*   

> 
> 
> A parer mio la risposta non può essere che NO non c'è bisogno. Ci sarebbe semmai bisogno di dare una bella sistemata a quello che già abbiamo e non tanto per non dover imparare qualcosa di nuovo, sono convinto che alla fine si tratterebbe di un'oretta di studio, ma perchè quel che c'è, sempre imho, basta e cresce ma potrebbe essere migliorato.
> 
> 

 

Il fatto di dare una sistemata è uno dei motivi cardine per cui è nato Paludis. Sistemare Portage (e non sono io a dirlo) è praticamente improponibile. Non è questione di un'ora.

Comunque sia tutti questi discorsi sono già stati affrontati lungo il thread e nel forum potrai facilmente ottenere ulteriori delucidazioni sul perché Portage ha dei problemi.

----------

## klaimath

x Lavish e Jordan83 

Scusate se non ho risposto ma non voglio andare OT. In ogni caso avete portato degli argomenti che, imho, varrebbe la pena approfondire in altra sede.

Ciao

----------

## drizztbsd

 *jordan83 wrote:*   

>  *klaimath wrote:*   
> 
> Se non ho capito male la discussione stiamo parlando di un gestore di pacchetti "alternativo" a portage, e fin qua non ci sarebbe niente di male, ma che in parte è scopiazzato pari pari da portage con solo alcuni nomi cambiati.
> 
>  
> ...

 Assolutamente no!

Paludis non cerca di essere compatibile con Portage, paludis è un client basato lo standard PMS (che è diversa come cosa); portage invece non rispetta pienamente lo standard PMS

 *jordan83 wrote:*   

> Per quanto riguarda la scopiazzatura... Credo tu abbia interpretato piuttosto erroneamente la situazione.
> 
> Paludis offre quello che offre Portage (meno il supporto per la generazione di pacchetti binari, in arrivo nelle prossime versioni) più un insieme più che considerevole di nuove funzionalità, di cui puoi avere un'idea qui:
> 
> - 1
> ...

 

Anche qui ti devo correggere, la gestione dei pacchetti binari viene lasciata a q appositamente (qpkg/qmerge) e non credo che verrà integrata per moooolto tempo

----------

## jordan83

 *Drizzt Do` Urden wrote:*   

> Assolutamente no!
> 
> Paludis non cerca di essere compatibile con Portage, paludis è un client basato lo standard PMS (che è diversa come cosa); portage invece non rispetta pienamente lo standard PMS
> 
> 

 

Uhm...

A me pareva che Ciaranm l'avesse messa in termini diversi. E comunque quello standard mi pare un po' sospetto...   :Laughing: 

Chi é che lo ha dichiarato "standard"?  :Razz: 

 *Drizzt Do` Urden wrote:*   

> 
> 
> Anche qui ti devo correggere, la gestione dei pacchetti binari viene lasciata a q appositamente (qpkg/qmerge) e non credo che verrà integrata per moooolto tempo
> 
> 

 

Io l'ho letta in termini diversi. Forse ho interpretato male questo e questo.

Tra l'altro qui si dice, testuali parole:

 *Quote:*   

> Binaries. Specifically, a decent binary package format and proper binary package handling. This is nearly done, and will be in before 1.0. (I keep saying "next major release", but then end up doing a release for a different new feature instead -- releasing often is helpful for everyone.)

 

Non mi pare che stiano tralasciando la cosa...   :Confused: 

Poi tu ovviamente ne sai piú di me, visto che se non erro partecipi al progetto...

----------

## Kernel78

 *jordan83 wrote:*   

>  *Drizzt Do` Urden wrote:*   Assolutamente no!
> 
> Paludis non cerca di essere compatibile con Portage, paludis è un client basato lo standard PMS (che è diversa come cosa); portage invece non rispetta pienamente lo standard PMS
> 
>  
> ...

 

 *il documento incriminato wrote:*   

>   Package Manager Speciﬁcation
> 
> Stephen P. Bennett         Ciaran McCreesh
> 
> spb@gentoo.org         ciaranm@ciaranm.org
> ...

 anche se la formattazione è andata a gambe all'aria è chiara la partecipazione di ciaranm  :Wink: 

----------

## drizztbsd

Beh paludis è PMS-compliant non portage compliant (infatti mplayer non lo installi manco se piangi).

PMS è stato approvato come standard nella scorsa riunione del Council (cerca nell'archivio di gentoo-dev) e questa versione dovrà essere approvata nella prossima riunione (sempre gentoo-dev).

E comunque spb è capo di QA e questo dovrebbe essere sufficente per dire cosa è valido e cosa non è valido.

Portage, invece, supporta anche della robaccia (tipo mplayer-1.0_rc2_pre20070321-r4) che paludis APPOSITAMENTE non supporta perché non è presente in PMS #166522 o altra roba secondaria (DEPEND=">=app-foo/foo-1.0*" non è valido in PMS/paludis ma è valido in portage)

----------

## Cazzantonio

 *Drizzt Do` Urden wrote:*   

> Portage, invece, supporta anche della robaccia (tipo mplayer-1.0_rc2_pre20070321-r4) che paludis APPOSITAMENTE non supporta perché non è presente in PMS #166522 o altra roba secondaria (DEPEND=">=app-foo/foo-1.0*" non è valido in PMS/paludis ma è valido in portage)

 

A seconda dei punti di vista questa cosa può essere variamente interpretata... forse per un devel è un bug di portage... dal mio punto di vista di semplice utente (ovvero l'unico valido imho ma anche questa è un'opinione) è un bug di paludis.   :Wink: 

----------

## Kernel78

 *Cazzantonio wrote:*   

> A seconda dei punti di vista questa cosa può essere variamente interpretata... forse per un devel è un bug di portage... dal mio punto di vista di semplice utente (ovvero l'unico valido imho ma anche questa è un'opinione) è un bug di paludis.  

 

Quindi per te se un sito si vede con IE ma non con FF, per mancato rispetto degli standard, si tratta di un bug di FF ?

Approfitto delle conoscenze di Drizzt per una perplessità: Paludis ha nel suo futuro un tentativo di essere "portage compliant" o di fornire overlay per i pacchetti che non sono PMS compliant o semplicemente se ne frega di detti pacchetti ?

----------

## Cazzantonio

 *Kernel78 wrote:*   

> Quindi per te se un sito si vede con IE ma non con FF, per mancato rispetto degli standard, si tratta di un bug di FF ?

 No ma è un discorso più complesso... si gioca sul fatto che gli standard web sono internazionali.

Quelli di portage sono standard interni quindi in qualche modo "più elastici"... diciamo che la capacità di riconoscere ebuild di vario genere va più nell'ottica della retrocompatibilità. Ovviamente partendo dal presupposto che anche ebuild scritti sui vecchi standard siano funzionanti (e pare di si).

Se vuoi fare un paragone trovo sia più calzante quello di msoffice che è scarsamente compatibili con i vecchi formati di versioni precedenti.

Comunque è un discorso del cazzo... sostanzialmente chi se ne frega. Visto che paludis non è il package manager ufficiale ma solo un progetto esterno può comportarsi un po' come gli pare (pure supportare un solo ebuild). Se mai volesse diventare ufficiale garantire la retrocompatibilità potrebbe essere una cosa simpatica.

----------

## yardbird

Domanda veloce, visto che sono un attimo bloccato: come faccio a smascherare un pacchetto hard-masked su package.mask e keywordato "-*"? Io ho provato ad aggiungerlo a /etc/paludis/package_unmask.conf e a mettere la linea

```
pacchetto_bastardo -* x86 ~x86
```

in /etc/paludis/keywords.conf ma paludis mi vede solo le versioni stabili (o al più ~x86). Sicuramente faccio qualche errore scemo, ma quale?   :Confused: 

----------

## jordan83

 *yardbird wrote:*   

> Domanda veloce, visto che sono un attimo bloccato: come faccio a smascherare un pacchetto hard-masked su package.mask e keywordato "-*"? Io ho provato ad aggiungerlo a /etc/paludis/package_unmask.conf e a mettere la linea
> 
> ```
> pacchetto_bastardo -* x86 ~x86
> ```
> ...

 

Non so bene come aiutarti, perché non ho mai smascherato pacchetti simili.

Forse qui puoi trovare una risposta.

Probabilmente devi:

- inserire il pacchetto in package_unmask.conf

- inserire la linea

```
pacchetto_bastardo * x86 ~x86
```

(senza il - ) in keywords.conf.

Per curiosità qual é il pacchetto incriminato?

----------

## yardbird

 *jordan83 wrote:*   

> Probabilmente devi:
> 
> - inserire il pacchetto in package_unmask.conf
> 
> - inserire la linea
> ...

 

Bingo! Funziona, grazie  :Smile: 

Il pacchetto incriminato è una pre-release del gcc-4.2 disponibile nel toolchain overlay. Per chiarire: so a cosa vado incontro e non intendo utilizzarlo per compilare i pacchetti di sistema  :Smile:  Mi serve per cominciare a sperimentare l'utilizzo di openMP, che è supportato appunto a partire da gcc 4.2.

Grazie ancora dell'aiuto  :Smile: 

----------

## lucapost

Sono famoso per essere un vero poliglotta: esiste una guida in italiano per imparare ad utilizzare paludis?

\EDIT

...come vedo la dimensione dei sorgenti da scaricare con paludis? quello che in emerge si vede con emerge -pv nome_pacchetto?

...mi postate i file di configurazione ad esempio di repository diciamo un pò inusuali, come quello di uno sviluppatore (pauldv oppure drizzt), cosa di metto come indirizzo rsync?

...(ne arriveranno delle altre...)

----------

## lucapost

Mi sa che ho combinato un piccolo casino... come faccio "ogni tanto" ho rimosso in contenuto in /var/tmp/* ed ora paludis non mi compila più nulla. Questo è l'eerore che ricevo provando a compilare qualsiasi pacchetto:

```
root@jarod {1} 

> ~/paludis -i tar

Building target list... paludis@1184172574: [WARNING] In program paludis -i tar:

  ... When performing install action from command line:

  ... When adding install target 'tar':

  ... When disambiguating package name 'tar':

  ... When looking in repository 'paludis-extras':

  ... When using name cache at '/var/cache/paludis/names/paludis-extras':

  ... Names cache for 'paludis-extras' has no version information, so cannot be used. Either it was generated using an older Paludis version or it has not yet been generated.

paludis@1184172574: [WARNING] In program paludis -i tar:

  ... When performing install action from command line:

  ... When adding install target 'tar':

  ... When disambiguating package name 'tar':

  ... When looking in repository 'sunrise':

  ... When using name cache at '/var/cache/paludis/names/sunrise':

  ... Names cache for 'sunrise' has no version information, so cannot be used. Either it was generated using an older Paludis version or it has not yet been generated.

Building dependency list...

These packages will be installed:

* app-arch/tar-1.17 {:0} [R] nls -static

Total: 1 package (1 rebuild)

elog> touch: cannot touch `//var/tmp/paludis/elog.10959': No such file or directory

elog> /usr/share/paludis/hooks/install_all_pre/elog.bash: line 48: die: command not found

elog> chgrp: cannot access `//var/tmp/paludis/elog.10959': No such file or directory

elog> /usr/share/paludis/hooks/install_all_pre/elog.bash: line 50: die: command not found

elog> chmod: cannot access `//var/tmp/paludis/elog.10959': No such file or directory

elog> /usr/share/paludis/hooks/install_all_pre/elog.bash: line 51: die: command not found

paludis@1184172574: [WARNING] Hook '/usr/share/paludis/hooks/install_all_pre/elog.bash' returned failure '127'

Install error:

  * In program paludis -i tar:

  * When performing install action from command line:

  * When executing install task:

  * Install error: Install aborted by hook

Resume command: paludis --log-level qa --dl-deps-default discard --install '=app-arch/tar-1.17::gentoo' --add-to-world-spec '( app-arch/tar )'
```

Poi mi sa che ci sono anche altre cose che non vanno, ho provato a seguire nuovamente il wiki per la reinstallazione, ma non arrivo a risolvere...

Qualcuno mi aiuta a mettere a posto il mio paludis?

----------

## Cazzantonio

paludis scrive dati permanenti su /var/tmp?

----------

## lucapost

Ho risolro da solo...ho temporaneamente commentato le righe che mi davavo errore del file /usr/share/paludis/hooks/install_all_pre/elog.bash, poi ho (riemerso?-->) paludiserso   :Laughing:  il pacchetto paludis-hooks e tutto sembra funzionare di nuovo (SEMBRA!!!).

Comunque mi da un pò fastidio che rimuovendo il contenuto di /var/tmp/ ma vada tutto in casino...

PS: Voi non sapete quante volte mi ha salvato il c**o commentare le righe che durante la compilazione di un pacchetto mi davano errore!

----------

## lucapost

Ma a voi funziona il resume dei download? 

Lancio il fetch del mio pacchetto:

```
root@jarod {0} 

> ~/paludis -if vanilla-sources

Building target list... 

Building dependency list...

These packages will be installed:

* sys-kernel/vanilla-sources-2.6.22.1 {:2.6.22.1} [N] -build -symlink

Total: 1 package (1 new)

(1 of 1) Fetching sys-kernel/vanilla-sources-2.6.22.1::gentoo

>>> Running ebuild phase fetch as paludisbuild:paludisbuild...

>>> Starting builtin_fetch

>>> Already have patch-2.6.22.1.bz2

>>> Need to fetch linux-2.6.22.tar.bz2

wget -T 30 -t 1 -O /usr/portage/distfiles/linux-2.6.22.tar.bz2 http://distfiles.gentoo.org/distfiles/linux-2.6.22.tar.bz2

--20:24:48--  http://distfiles.gentoo.org/distfiles/linux-2.6.22.tar.bz2

           => `/usr/portage/distfiles/linux-2.6.22.tar.bz2'

Resolving distfiles.gentoo.org... 64.50.238.52, 64.50.236.52, 216.165.129.135, ...

Connecting to distfiles.gentoo.org|64.50.238.52|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 45,119,878 (43M) [application/x-tar]

 0% [                                                                                                                ] 30,118         3.54K/s  ETA 3:28:00sandbox:  Caught signal 2 in pid 6303

Caught signal 2

Waiting for children...

Exiting with failure
```

lo termino con ctrl+c e rilancio lo stesso comando, ma ricevo questo errore:

```
> ~/paludis -if vanilla-sources

Building target list... 

Building dependency list...

These packages will be installed:

* sys-kernel/vanilla-sources-2.6.22.1 {:2.6.22.1} [N] -build -symlink

Total: 1 package (1 new)

(1 of 1) Fetching sys-kernel/vanilla-sources-2.6.22.1::gentoo

paludis@1184265008: [WARNING] In program paludis -if vanilla-sources:

  ... When performing install action from command line:

  ... When executing install task:

  ... When installing 'sys-kernel/vanilla-sources-2.6.22.1':

  ... When checking permissions on '/usr/portage/distfiles' for userpriv:

  ... Directory '/usr/portage/distfiles' owned by group 'root', not 'paludisbuild', so cannot enable userpriv

>>> Running ebuild phase fetch as root:root...

>>> Starting builtin_fetch

>>> Already have patch-2.6.22.1.bz2

>>> Already have linux-2.6.22.tar.bz2

 * Checking MD5 for linux-2.6.22.tar.bz2 ...                             [ !! ]

 * Checking RMD160 for linux-2.6.22.tar.bz2 ...                          [ !! ]

 * Checking SHA256 for linux-2.6.22.tar.bz2 ...                          [ !! ]

 * Checking MD5 for patch-2.6.22.1.bz2 ...                               [ ok ]

 * Checking RMD160 for patch-2.6.22.1.bz2 ...                            [ ok ]

 * Checking SHA256 for patch-2.6.22.1.bz2 ...                            [ ok ]

 * Bad digests encountered for the following components:

 *   * linux-2.6.22.tar.bz2

!!! ERROR in sys-kernel/vanilla-sources-2.6.22.1:

!!! In builtin_fetch at line 116

!!! builtin_fetch failed

!!! Call stack:

!!!    * builtin_fetch (/usr/libexec/paludis/builtin_fetch.bash:116)

!!!    * ebuild_f_fetch (/usr/libexec/paludis/builtin_fetch.bash:130)

!!!    * ebuild_main (/usr/libexec/paludis/ebuild.bash:363)

!!!    * main (/usr/libexec/paludis/ebuild.bash:381)

die trap: exiting with error.

Fetch error:

  * In program paludis -if vanilla-sources:

  * When performing install action from command line:

  * When executing install task:

  * When installing 'sys-kernel/vanilla-sources-2.6.22.1':

  * Fetch error: Fetch failed for 'sys-kernel/vanilla-sources-2.6.22.1::gentoo'

```

leggo... e quindi cambio i permessi ai distfiles:

```
> ~/chown -R root:paludisbuild /usr/portage/distfiles/
```

rilancio il fetch, ed ottengo:

```
> ~/paludis -if vanilla-sources

Building target list... 

Building dependency list...

These packages will be installed:

* sys-kernel/vanilla-sources-2.6.22.1 {:2.6.22.1} [N] -build -symlink

Total: 1 package (1 new)

(1 of 1) Fetching sys-kernel/vanilla-sources-2.6.22.1::gentoo

>>> Running ebuild phase fetch as paludisbuild:paludisbuild...

>>> Starting builtin_fetch

>>> Already have patch-2.6.22.1.bz2

>>> Already have linux-2.6.22.tar.bz2

 * Checking MD5 for linux-2.6.22.tar.bz2 ...                             [ !! ]

 * Checking RMD160 for linux-2.6.22.tar.bz2 ...                          [ !! ]

 * Checking SHA256 for linux-2.6.22.tar.bz2 ...                          [ !! ]

 * Checking MD5 for patch-2.6.22.1.bz2 ...                               [ ok ]

 * Checking RMD160 for patch-2.6.22.1.bz2 ...                            [ ok ]

 * Checking SHA256 for patch-2.6.22.1.bz2 ...                            [ ok ]

 * Bad digests encountered for the following components:

/usr/share/paludis/hooks/eerror/elog.bash: line 43: //var/tmp/paludis/elog.7103: Permission denied

/usr/libexec/paludis/ebuild.bash@1184265185: [WARNING.EBUILD] Hook '/usr/share/paludis/hooks/eerror/elog.bash' returned failure (from /usr/portage/sys-kernel/vanilla-sources/vanilla-sources-2.6.22.1.ebuild)

 *   * linux-2.6.22.tar.bz2

/usr/share/paludis/hooks/eerror/elog.bash: line 43: //var/tmp/paludis/elog.7103: Permission denied

/usr/libexec/paludis/ebuild.bash@1184265185: [WARNING.EBUILD] Hook '/usr/share/paludis/hooks/eerror/elog.bash' returned failure (from /usr/portage/sys-kernel/vanilla-sources/vanilla-sources-2.6.22.1.ebuild)

!!! ERROR in sys-kernel/vanilla-sources-2.6.22.1:

!!! In builtin_fetch at line 116

!!! builtin_fetch failed

!!! Call stack:

!!!    * builtin_fetch (/usr/libexec/paludis/builtin_fetch.bash:116)

!!!    * ebuild_f_fetch (/usr/libexec/paludis/builtin_fetch.bash:130)

!!!    * ebuild_main (/usr/libexec/paludis/ebuild.bash:363)

!!!    * main (/usr/libexec/paludis/ebuild.bash:381)

die trap: exiting with error.

Fetch error:

  * In program paludis -if vanilla-sources:

  * When performing install action from command line:

  * When executing install task:

  * When installing 'sys-kernel/vanilla-sources-2.6.22.1':

  * Fetch error: Fetch failed for 'sys-kernel/vanilla-sources-2.6.22.1::gentoo'
```

ora che permessi deve avere /var/tmp/paludis? io c'è l'ho root:root, voi?

Poi, un'altro quesito, ho installato dall'overlay paludis-extra il pacchetto paludis-hooks-update-eix, ma dopo aver lanciato update-eix, eix non trova più i pacchetti degli overlay di paludis.  Però, subito dopo un "paludis -s" sembrava funzionare bene...chi mi aiuta?

----------

## topper_harley

 *lucapost wrote:*   

> 
> 
> Poi, un'altro quesito, ho installato dall'overlay paludis-extra il pacchetto paludis-hooks-update-eix, ma dopo aver lanciato update-eix, eix non trova più i pacchetti degli overlay di paludis.  Però, subito dopo un "paludis -s" sembrava funzionare bene...chi mi aiuta?

 

Devi abilitarlo con eselect, se non lo hai già fatto.

```
eselect paludis-hook enable update-eix
```

Ps: un modo pulito per installare gli hooks, senza inserire ogni singola voce in /etc/paludis/use.conf è questo:

```

apocalipse ~ # cat /etc/paludis/use.conf | grep PALUDIS_HOOKS

*/* PALUDIS_HOOKS: eselect update-eix ask

```

Una volta aggiunta questa riga basta lanciare:

```
 paludis --dl-reinstall if-use-changed -i world 
```

----------

## lucapost

è gia abilitato:

 *Quote:*   

> > ~/eselect paludis-hook list
> 
> Managable hooks:
> 
>   demos-elog                enabled
> ...

 

mi sembra che però funga solamente dopo un "paludis -s", appena faccio "update-eix" non trova più gli ebuild in overlay

----------

## topper_harley

 *lucapost wrote:*   

> 
> 
> mi sembra che però funga solamente dopo un "paludis -s", appena faccio "update-eix" non trova più gli ebuild in overlay

 

Infatti non devi piu' fare update-eix... Basta un paludis --sync per aggiornare tutto, e evere anche un bellissimo output degli aggiornamenti di eix  :Smile: 

----------

## lucapost

 *topper_harley wrote:*   

> 
> 
> Infatti non devi piu' fare update-eix... Basta un paludis --sync per aggiornare tutto, e evere anche un bellissimo output degli aggiornamenti di eix 

 

ma quando aggiungo un ebuild al mio overlay locale, magari un ebuild che mi sono scaricato da bugzilla, devo per forza fare un "paludis -s" per farlo vedere da eix?

----------

## topper_harley

 *lucapost wrote:*   

> 
> 
> ma quando aggiungo un ebuild al mio overlay locale, magari un ebuild che mi sono scaricato da bugzilla, devo per forza fare un "paludis -s" per farlo vedere da eix?

 

Si, ma non devi necessariamente syncare tutto.

Nel mio caso per esempio l'overlay locale dove metto gli ebuil di bugzilla si chiama "local" (si, lo so... non sono molto fantasioso), quindi mi basta un bel:

```
 paludis --sync local 
```

----------

## lucapost

ok, eix funge correttamente, devo quindi dimenticarmi update-eix, grazie dell'aiuto.

ho anche imparato qualcosa sulla gestione degli overlay (playman...)

E per gli altri quesiti:

il resume dei download, a te funziona correttamente?

come vedo la quantità di sorgenti da dover scaricare (emerge -pv ...)?

----------

## lucapost

il resume dei download, a te funziona correttamente?

per questo ho trovato la soluzione, bisogna passare a paludis l'opzione --safe-resume, anche se funziona solo dopo aver scaricato più di qualche centinaio di Kb di sorgente.

come vedo la quantità di sorgenti da dover scaricare (emerge -pv ...)?

Qui non so proprio ancora come far a meno di emerge...

----------

## lucapost

In alcuni thread ho letto che il supporto a paludis per visualizzare alcune informazioni sulla dimensione dei sorgenti verrà implementeto quando verrà introdotto manifest2...

----------

## jordan83

Paludis 0.26.0_alpha4

Ho deciso di rispolverare questo vecchio thread e di aggiungere le ultime novità introdotte in Paludis.

Per avere informazioni più dettagliate su questo software è sufficiente visitare i link riportati al termine del post o leggere i post precedenti (soprattutto il primo).

Se guardate nella pagina delle "Release Notes" noterete che ci sono stati cambiamenti notevoli dalla versione 0.20.2, una delle ultime menzionate in questo thread.

Nel mucchio:

 Supporto dei file di configurazione di Portage, nel caso uno volesse "facilitarsi" la migrazione. La cosa migliore ovviamente è avere dei file di configurazione originali per Paludis.

 Maggiore rigidità nella valutazione della qualità degli ebuild.

 Maggiore conformità al "Package Manager Specification" (per maggiori informazioni vedi qua e qua)

 Python bindings, per scrivere applicazioni in python che possano interfacciarsi a Paludis

 Miglioramenti vari al sistema degli hook con supporto a hook di diverso tipo.

 Miglioramento della documentazione

 introduzione di accerso, un client per gestire un mirror (per developers) 

 introduzione di instruo, per generare metadata (per developers) 

 introduzione di reconcilio, un client che rimpiazza revdep-rebuild

 introduzione di importare, un client che permette di gestire pacchetti non pacchettizzati (non ho ancora ben capito a che potrebbe servire a dire il vero...  :Razz:  )

 Miglioramenti interni e degli output.

 Aggiunta di un bel tot di opzioni, come ad esempio --dl-suggested in quanto Paludis adesso è in grado di "suggerire" dipendenze ma anche nomi di pacchetti. Ad esempio, se un certo pacchetto non viene trovato in una query:

```

$ paludis -q k3c

Query error:

  * In program paludis -q k3c:

  * When performing query action from command line:

  * When handling query 'k3c':

  * When disambiguating package name 'k3c':

  * Could not find 'k3c'. Looking for suggestions:

Suggestions:

  * app-cdr/k3b

  * app-i18n/kcc

  * media-gfx/k3d

```

Edit 28/12/2007

Aggiungo un altro esempio interessante. Supponiamo io voglia disinstallare python:

```

# paludis -u dev-lang/python

Building unmerge list... done

These packages will be uninstalled:

[... ne ho tagliati un tot]

* gnome-extra/libgsf-1.14.7::installed requires <dev-lang/python-2.4.4-r6:2.4::installed>

* media-gfx/fontforge-20070831::installed requires <dev-lang/python-2.4.4-r6:2.4::installed>

* media-gfx/graphviz-2.12::installed requires <dev-lang/python-2.4.4-r6:2.4::installed>

* media-libs/lcms-1.15::installed requires <dev-lang/python-2.4.4-r6:2.4::installed>

* net-fs/samba-3.0.28::installed requires <dev-lang/python-2.4.4-r6:2.4::installed>

* sys-apps/paludis-0.26.0_alpha4::installed requires <dev-lang/python-2.4.4-r6:2.4::installed>

* sys-apps/portage-2.1.3.19::installed requires <dev-lang/python-2.4.4-r6:2.4::installed>

* sys-libs/cracklib-2.8.10::installed requires <dev-lang/python-2.4.4-r6:2.4::installed>

* dev-lang/python-2.4.4-r6:2.4::installed

Total: 1 package and 28 errors

Use either --with-dependencies or --permit-unsafe-uninstalls

Cannot continue with uninstall due to the errors indicated above

```

Come vedete Paludis fa attenzione a mantenere il sistema consistente. Difficilmente vi permetterà di disinstallare per errore pacchetti di base come "python" o "gcc".

Portage qui si sarebbe letteralmente "suicidato" senza problemi e senza battere ciglio (a meno che qualcosa non sia cambiato ultimamente, visto che non lo uso da una vita) ...  :Wink: 

Come vedete le novità sono parecchie. Paludis sta diventando un prodotto sempre più maturo e completo.

Paludis è inoltre affidabile, lo posso testimoniare io che in un anno di utilizzo non stop non ho incontrato un problema, così come i molti utenti che lo usano da tempo senza avere noie degne di nota. Se leggete il thread ufficiale in inglese potrete farvi un'idea voi stessi.

Le mancanze che personalmente riscontro al momento sono:

 Non è possibile generare pacchetti binari

 Per un dato pacchetto solo lo slot più recente (invece che tutti quelli installati) viene aggiornato (vedi questo bug report).

Per quanto riguarda gli sviluppatori, anche qui Paludis sta migliorando velocemente.

È diventato ancora più rigido e severo nel verificare che un ebuild sia conforme a degli standard minimi di qualità, inoltre sono stati aggiunti e/o migliorati diversi strumenti che possono semplificare la vita allo sviluppatore di ebuild.

Altra cosa secondo me interessante sono i bindings, cioè le interfacce che permettono di usare Paludis con linguaggi diversi dal C++.

Al momento sono disponibili i bindings per:

 C++

 Ruby

 Python

 (Java??)

Personalmente spero si continui così, magari Paludis darà una mano a risollevare gli standard qualitativi di Gentoo...  :Wink: 

Se veniste colti dalla voglia di provarlo, sappiate che il passaggio a Paludis è praticamente indolore (vedi guida nel wiki) così come il percorso inverso nel caso cambiaste idea e voleste tornare a Portage.

Se volete contribuire...

 :Arrow:  HOME PAGE

 :Arrow:  Paludis Extras

 :Arrow:  GENTOO-WIKI PAGE

 :Arrow:  THREAD UFFICIALE IN INGLESE (per la versione corrente)

 :Arrow:  PLANET PALUDIS

----------

## lavish

 *jordan83 wrote:*   

> Come vedete Paludis fa attenzione a mantenere il sistema consistente. Difficilmente vi permetterà di disinstallare per errore pacchetti di base come "python" o "gcc".
> 
> Portage qui si sarebbe letteralmente "suicidato" senza problemi e senza battere ciglio

 

```
# emerge -C python

!!! 'dev-lang/python' is part of your system profile.

!!! Unmerging it may be damaging to your system.

>>> Waiting 10 seconds before starting...

>>> (Control-C to abort)...

Press Ctrl-C to Stop in: 10 9 8 7 6 5 4  [...]
```

----------

## jordan83

 *lavish wrote:*   

> [...]

 

Mea culpa... avevo dimenticato il conto alla rovescia.

Comunque sia, Portage secondo me dovrebbe bloccarsi in questi casi, non dare 10 secondi di tempo per cambiare idea.

Ci dovrebbe essere uno switch tipo --force per indicare la precisa volontà dell'utente di disinstallare un pacchetto di sistema.

Così è un suicidio con il conto alla rovescia... ^_^

Un esempio (certo sempliciotto) potrebbe essere quello dove un "utonto" crede di non aver bisogno di "python" (non sa che Portage lo richiede per funzionare) e lancia un comando del tipo

```
emerge -uDNav world && emerge -C python
```

e poi va a dormire. Al risveglio ha ottime possibilità di trovarsi Gentoo inutilizzabile, a meno che Portage non si sia inchiodato durante l'aggiornamento di world.

Ci potrebbero essere molti altri casi in cui una situazione del genere può verificarsi. Non per niente, se non ricordo male, più o meno tutti i package managers si bloccano in questo tipo di situazione.

----------

## jordan83

 *lucapost wrote:*   

> 
> 
> come vedo la quantità di sorgenti da dover scaricare (emerge -pv ...)?

 

Implementato in Paludis 0.26.0_alpha5, uscito ieri. Dalle Release Notes:

 *Quote:*   

> 
> 
> * paludis --install --pretend will show how many bytes still need to be downloaded for a given package to be installed. Two new metadata keys, size_of_download_required and size_of_all_distfiles, have been added.
> 
> 

 

----------

## lucapost

 *jordan83 wrote:*   

>  *lucapost wrote:*   
> 
> come vedo la quantità di sorgenti da dover scaricare (emerge -pv ...)? 
> 
> Implementato in Paludis 0.26.0_alpha5, uscito ieri. Dalle Release Notes:
> ...

 

bene, dopo qualche mese, è il momento di dare una nuova possibilità a paludis!   :Very Happy: 

----------

## jordan83

Vorrei segnalare un'interessante script che è possibile trovare nel repository SVN di Paludis ma che non è ancora stato incluso in alcuna release.

Si tratta di config-decruft, uno script ruby che sfruttando i "ruby bindings" offerti da Paludis è in grado di permettere la pulizia dei file di configurazione di Paludis.

Io lo uso ogni tanto e devo dire che è davvero utilissimo  :Smile: 

Un esempio dell'output (ho separato le diverse parti per aumentarne la leggibilità):

```

# ruby config-decruft --log-level warning

 * Checking /etc/paludis/keywords.conf (pass 1/2)

 * Checking /etc/paludis/keywords.conf (pass 2/2)

app-office/taskjuggler: not installed

net-voip/wengophone-bin: not installed

games-fps/worldofpadman: not installed

app-cdr/k9copy: not installed

net-im/skype: net-im/skype-2.0.0.27:0::installed installed, net-im/skype-1.4.0.118:0::gentoo available with keywords x86

kde-misc/kdmtheme: kde-misc/kdmtheme-1.2.2:0::installed installed, kde-misc/kdmtheme-1.2.2:0::gentoo available with keywords x86

x11-themes/domino: x11-themes/domino-0.4:0::installed installed, x11-themes/domino-0.4:0::gentoo available with keywords x86

app-admin/eselect: app-admin/eselect-1.0.11:0::installed installed, app-admin/eselect-1.0.10:0::gentoo available with keywords x86

dev-libs/libnl: dev-libs/libnl-1.0_pre6-r1:0::installed installed, dev-libs/libnl-1.0_pre6:0::gentoo available with keywords x86

dev-cpp/libwrapiter: not installed

=app-doc/doxygen-1.5.3: not installed

sys-fs/ntfs3g: sys-fs/ntfs3g-1.1120:0::installed installed, sys-fs/ntfs3g-1.810:0::gentoo available with keywords x86

<=media-sound/alsa-driver-1.0.15: media-sound/alsa-driver-1.0.15:0::installed installed, media-sound/alsa-driver-1.0.14-r1:0::gentoo available with keywords x86

<=media-sound/alsa-headers-1.0.15: media-sound/alsa-headers-1.0.15:0::installed installed, media-sound/alsa-headers-1.0.14:0::gentoo available with keywords x86

media-video/linux-uvc: specified more than once

games-fps/nexuiz: games-fps/nexuiz-2.3:0::installed installed, games-fps/nexuiz-2.3:0::gentoo available with keywords x86

net-im/amsn: net-im/amsn-0.97:0::installed installed, net-im/amsn-0.96-r1:0::gentoo available with keywords x86

app-emulation/vmware-player: app-emulation/vmware-player-2.0.2.59824:0::installed installed, app-emulation/vmware-player-1.0.5.56455:0::gentoo available with keywords x86

app-emulation/vmware-modules: app-emulation/vmware-modules-1.0.0.17:0::installed installed, app-emulation/vmware-modules-1.0.0.15-r1:0::gentoo available with keywords x86

app-emulation/vmware-workstation: not installed

x11-libs/libview: not installed

dev-cpp/libsexymm: not installed

kde-base/kopete: kde-base/kopete-3.5.8:3.5::installed installed, kde-base/kopete-3.5.7:3.5::gentoo available with keywords x86

app-text/acroread: app-text/acroread-8.1.1:0::installed installed, app-text/acroread-7.0.9-r1:0::gentoo available with keywords x86

 * Checking /etc/paludis/use.conf (pass 1/2)

 * Checking /etc/paludis/use.conf (pass 2/2)

*/*: aiglx not used by any matching installed packages

*/*: asf not used by any matching installed packages

*/*: dbx not used by any matching installed packages

*/*: divx not used by any matching installed packages

*/*: ethereal not used by any matching installed packages

*/*: fat not used by any matching installed packages

*/*: fbsplash not used by any matching installed packages

*/*: gatos not used by any matching installed packages

*/*: glut not used by any matching installed packages

*/*: gmedia not used by any matching installed packages

*/*: gzip not used by any matching installed packages

*/*: icq not used by any matching installed packages

*/*: jabber not used by any matching installed packages

*/*: logrotate not used by any matching installed packages

*/*: matroska not used by any matching installed packages

*/*: mbox not used by any matching installed packages

*/*: mime not used by any matching installed packages

*/*: msn not used by any matching installed packages

*/*: nowin not used by any matching installed packages

*/*: realmedia not used by any matching installed packages

*/*: userlocales not used by any matching installed packages

*/*: vhosts not used by any matching installed packages

*/*: wmp not used by any matching installed packages

*/*: xosd not used by any matching installed packages

*/*: eds not used by any matching installed packages

*/*: emboss not used by any matching installed packages

*/*: isdnlog not used by any matching installed packages

*/*: pppd not used by any matching installed packages

*/*: APACHE2_MODULES: so not used by any matching installed packages

x11-libs/gtk+: x11-libs/gtk+-1.2.10-r12:1::installed installed from gentoo, does not use doc

dev-util/eclipse-sdk: not installed

x11-libs/qt: x11-libs/qt-3.3.8-r4:3::installed installed from gentoo, does not use accessibility

games-fps/worldofpadman: not installed

media-sound/alsa-driver: media-sound/alsa-driver-1.0.15:0::installed installed from gentoo, does not use hda-intel

app-text/acroread: not installed

dev-java/swt: not installed

 * Checking /etc/paludis/package_mask.conf

<=x11-libs/qt-3.3.8-r3: installed version x11-libs/qt-3.3.8-r4:3::installed is higher than highest masked version x11-libs/qt-3.3.4-r8:3::gentoo

<x11-libs/qt-4.3.2-r1:4: installed version x11-libs/qt-4.3.2-r1:4::installed is higher than highest masked version x11-libs/qt-4.3.2:4::gentoo

 * Checking /etc/paludis/package_unmask.conf

net-wireless/iwl4965-ucode: net-wireless/iwl4965-ucode-4.44.1.20:0::installed installed, net-wireless/iwl4965-ucode-4.44.1.20:0::gentoo available and not masked

app-text/acroread: app-text/acroread-8.1.1:0::installed installed, app-text/acroread-7.0.9-r1:0::gentoo available and not masked

net-im/skype: net-im/skype-2.0.0.27:0::installed installed, net-im/skype-1.4.0.118:0::gentoo available and not masked
```

Ovviamente quando lanciate lo script da console l'output risulta convenientemente colorato ed è ben più leggibile...  :Wink: 

Come vedete ci sono un bel po' di entry che vanno rimosse nei vary file di configurazione, pacchetti che io avevo smascherato e che ora sono stabili e use flag che non esistono più o che non sono utilizzate nel mio sistema e che posso rimuovere. 

Certo poi sta all'utente capire quali parti dell'output considerare e quali ignorare.

Un esempio potrebbe essere amsn:

```

net-im/amsn: net-im/amsn-0.97:0::installed installed, net-im/amsn-0.96-r1:0::gentoo available with keywords x86
```

Ovviamente io voglio tenere la versione 0.97 sebbene lo script mi segnali che esiste una versione non mascherata da keyword ~x86...  :Wink: 

Lo script non è certo definitivo, tuttavia funziona egregiamente già da adesso.

Lo potete trovare qua.

----------

## flocchini

in settimana provero' sicuramente paludis, mi sorge pero' spontanea una domanda: al di la' dei SET di pacchetti (che per ora non usero'), quali sono le altre condizioni per tornare in 2 click a portage? Ok che ho i miei stage4 settimanali, ma potendolo preferirei evitare  :Wink: 

Trovo paludis davvero geniale, ormai si merita almeno di essere provato anche se le comodita' e l'efficienza in piu' devono valere il numero di pacchetti che non compila causa ebuild balordi. E questo devo valutarlo di persona perche' un package manager senza package e' un po' inutile :p

----------

## jordan83

 *flocchini wrote:*   

> in settimana provero' sicuramente paludis, mi sorge pero' spontanea una domanda: al di la' dei SET di pacchetti (che per ora non usero'), quali sono le altre condizioni per tornare in 2 click a portage? Ok che ho i miei stage4 settimanali, ma potendolo preferirei evitare 
> 
> 

 

Dunque:

- Paludis crea la sua directory per i files di configurazione in /etc/paludis

- Praticamente tutte le directory usate da Paludis sono separate da quelle di Portage (a meno che tu non decida diversamente ovviamente)

Gli unici punti in cui Portage e Paludis "collidono" sono:

- il tree di Gentoo, a meno che tu non decida di avere un tree "separato" dedicato a Paludis, che magari puoi collocare in /var/paludis/repositories/gentoo. Nel mio caso ad esempio:

```

$ cat /etc/paludis/repositories/gentoo.conf

location = ${ROOT}/var/paludis/repositories/gentoo

#sync = rsync://rsync.europe.gentoo.org/gentoo-portage

sync = rsync://rsync.gentoo.org/gentoo-portage

format = ebuild

names_cache = ${location}/.cache/names

write_cache = /var/cache/paludis/metadata

```

anche se a dire il vero io non ho due tree diversi...

```

$ ls -l /usr/portage

lrwxrwxrwx 1 root root 32 2007-09-04 11:10 /usr/portage -> /var/paludis/repositories/gentoo

```

Ho spostato il tree in quella directory perché in effetti gli sviluppatori di Paludis facevano notare che il tree è "variabile" nel tempo e il suo posto è decisamente in /var e non in /usr. Non ho potuto che dargli ragione.

Io piazzo tutti i repository (in Paludis gli overlay non sono altro che repository come lo è il tree ufficiale) in /var/paludis/repositories/.

Si tratta di scelte "filosofiche" comunque, nulla di fondamentale  :Wink:  Piazza pure la tua "roba" dove credi...

- la directory /var/db/pkg dove vengono piazzati i file relativi ai pacchetti installati + il file world. Se usi lo script portage2paludis per convertire la tua configurazione a quella di Paludis, il file world viene spostato in questa directory e viene creato un link ad esso in /var/lib/portage/world:

```

ls -l /var/lib/portage/world

lrwxrwxrwx 1 root portage 17 2007-09-04 11:42 /var/lib/portage/world -> /var/db/pkg/world

```

Quindi se decidessi di tornare indietro, a livello di "files" praticamente al max dovrai rispostare il file world e cancellare il tree che hai usato per Paludis...  :Wink: 

Se decidessi di usare i set basterà che ti ricordi di cancellarli dal  file world una volta tornato a Portage (ma fidati che lui te lo ricorderà, molto probabilmente...).

Non c'è altro, almeno da quel che mi viene in mente (tieni conto che io non sono mai tornato a Portage). Dovessero proprio spuntare problemi astrusi con un pacchetto basterà ricompilarlo con Portage.

Comunque sia non ho mai letto lamentele di gente che è tornata a Portage (anche perché moltissimi non tornano a Portage  :Smile:  ) nei forum.

 *flocchini wrote:*   

> 
> 
> Trovo paludis davvero geniale, ormai si merita almeno di essere provato anche se le comodita' e l'efficienza in piu' devono valere il numero di pacchetti che non compila causa ebuild balordi. E questo devo valutarlo di persona perche' un package manager senza package e' un po' inutile :p

 

Non credere  :Smile: 

Al momento è un po' di manica larga (si limita a stampare "warning" e "qa errors" a manica) perché sennò non lo potresti utilizzare...

Per lo stesso motivo ricordati di disabilitare il lancio delle suite di test dei pacchetti, sennò un tot di essi non compilerà:

```

export SKIP_FUNCTIONS="test"

```

Puoi anche disabilitare i test "selettivamente".

I problemi che riscontrerai nell'utilizzo di Paludis saranno molto probabilmente soltanto di "ambientamento".

Se hai domande/problemi sarò felice di aiutarti  :Smile: 

Ormai Paludis lo conosco benone  :Wink: 

----------

## flocchini

ti ringrazio, sicuramente ti stressero' in caso di problemi (speriamo di no :p) A quanto pare sembra abbastanza lineare come cosa, vedremo sul campo  :Smile: 

Mi sfugge in cosa siano diversi i tree (a aprte la locazione) visto che sia portage sia paludis usano gli ebuild: forse digest e compagnia bella? Immagino avro' comunque {portage_dir|paludis_dir}/app-misc/pippo/pippo-2.1-r5.ebuild no? Cmq, mi sembra marginale, posso permettermi di tenere cmq 2 copie di portage. Puo' partire la sperimentazione  :Wink: 

----------

## jordan83

 *flocchini wrote:*   

> ti ringrazio, sicuramente ti stressero' in caso di problemi (speriamo di no :p) A quanto pare sembra abbastanza lineare come cosa, vedremo sul campo 
> 
> Mi sfugge in cosa siano diversi i tree (a aprte la locazione) visto che sia portage sia paludis usano gli ebuild: forse digest e compagnia bella? Immagino avro' comunque {portage_dir|paludis_dir}/app-misc/pippo/pippo-2.1-r5.ebuild no? Cmq, mi sembra marginale, posso permettermi di tenere cmq 2 copie di portage. Puo' partire la sperimentazione 

 

Confermo che i due tree differirebbero solo per la locazione. 

Ora che ci penso comunque non ha neanche tanto senso averne due ^_^

È solo spazio sprecato, visto che in entrambi i casi "l'attore" è rsync e se non fa "danni" con Portage di certo non ne fa con Paludis  :Smile: 

----------

## flocchini

primo problema: emerso paludis, non vi e' traccia dello script di migrazione. I link agli howto di migrazione portano a pagine inesistenti, il sito ufficiale non dice nulla sulla migrazione ne' tantomeno sulle useflag del pacchetto. Come approccio non e' un granche' onestamente, provo a riemergerlo con la flag "portage" e vediamo cosa succede.... Dico io, dovrebbe essere la prima cosa scritta in testa alla documentazione ufficiale visto che il 99% dell'utenza arriva da portage... Sono ciecato io?

----------

## jordan83

 *flocchini wrote:*   

> primo problema: emerso paludis, non vi e' traccia dello script di migrazione. I link agli howto di migrazione portano a pagine inesistenti, il sito ufficiale non dice nulla sulla migrazione ne' tantomeno sulle useflag del pacchetto.

 

Uhm, guarda che la prima sezione della home page é "Overview" e subito sotto trovi "Getting Started".

Forse hai dato un'occhiata troppo veloce  :Wink: 

Lo script non é compreso in paludis, é fornito in quella pagina.

Quali sarebbero i link che non funzionano? Cosí li possiamo correggere o far correggere  :Wink: 

Per informazioni sulle USE flags:

```

euse -i useflag

```

cosí come faresti per qualsiasi pacchetto.

Se hai altri problemi spara  :Smile: 

----------

## flocchini

ok la prima figura di m l'ho fatta, sotto con la prossima  :Laughing: 

per le use ho gia' usato euse, ma  e' sempre un po' poco verboso per i miei gusti, speravo in qsa di piu' esaustivo... a sto punto riemergo senza la flag portage che dubito mi serva

tnx  :Smile: 

PS i link morti sono tutti quelli che puntano all'howto x la migrazione in http://paludis.pioto.org/migration.html che non esiste piu'

----------

## flocchini

mi appaiono strani messaggi, che per ora non riesco a interpretare: 

```
sovereign flocchini # paludis --sync

paludis@1201187022: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187022: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

... e poi parte a syncare il portage... poi finisce e 

 * Cleaning write cache for ebuild format repositories...

paludis@1201187231: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187231: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

paludis@1201187231: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187231: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

paludis@1201187231: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187231: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

rm -fr /var/cache/paludis/metadata/x-portage/*

paludis@1201187232: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187232: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

rm -fr /var/cache/paludis/metadata/sabayon/*

paludis@1201187236: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187236: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

rm -fr /var/cache/paludis/metadata/sunrise/*

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

rm -fr /var/cache/paludis/metadata/vmware/*

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

rm -fr /var/cache/paludis/metadata/xeffects/*

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

rm -fr /var/cache/paludis/metadata/zugaina/*

 * Done cleaning write cache for ebuild format repositories

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201187239: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

 * You have 1 unread news items (use 'eselect news' to read)

sovereign flocchini # eselect news

Usage: eselect news <action> <options>

Standard actions:

  help                      Display help text

  usage                     Display usage information

  version                   Display version information

Extra actions:

  count                     Show number of unread news items

  list                      List news items

  purge                     Purge read news items

  read <target>             Read a news item

    target                    News item ID (from 'list'action), or the special item 'new', to list

                              all new news items, or 'all', to show all items

  unread <target>           Unread a news item

    target                    News item ID (from 'list'action), or the special item 'all', to mark

                              all items as unread

sovereign flocchini # eselect read 1

!!! Error: Can't load module read

Killed

sovereign flocchini # eselect read list

!!! Error: Can't load module read

Killed

sovereign flocchini # 

```

domanda: come faccio a eliminare un overlay adesso (ne ho dentro di non validi, tipo xeffects) ? agisco sempre con layman e poi rigenero la cache di paludis giusto?

E quella roba li' di eselect da dove spunta? E' dovuta a paludis o ad altro?  :Rolling Eyes: 

Mi trovo piu' spiazzato del previsto onestamente

EDIT: telecronaca diretta, ora sono 5 minuti buoni che sta cercando le dipendenze di keyboard-config dopo che ho seccato xkbdata nonostante sue le giuste rimostranze... l'avevo installato qualche giorno fa x fare delle prove cn la tastiera e ora vogli orimettere keyboard-config che e' il default

EDIT 2: dopo mezzora a scansionarsi tutti gli ebuild del mio sistema (immagino perche' fosse la prima volta, almeno lo spero  :Laughing: ) pare che sia d'accordo sull'installazione di xkeyboard-config, nonostante continui a spararmi fuori l'errore 

```
paludis@1201189165: [QA] Couldn't open repo_name file in '/usr/local/portage/profiles/', falling back to generated name 'x-portage' (ignore this message if you have yet to sync this repository).

paludis@1201189165: [QA] Couldn't open repo_name file in '/usr/local/layman/wschlich-testing/profiles/', falling back to generated name 'x-wschlich-testing' (ignore this message if you have yet to sync this repository).

```

che a sto punto credo sia dovuto ad un overlay fatto a pene di segugio piu' che a un effettivo problema di paludis

----------

## jordan83

 *flocchini wrote:*   

> mi appaiono strani messaggi, che per ora non riesco a interpretare: 
> 
> ```
> sovereign flocchini # paludis --sync
> 
> ...

 

Dunque quei messaggi sono di "Quality Assurance". Ti sta dicendo che non riesce a trovare la cartella "profile" dei repository. Ciò accade operché è la prima volta che fai il sync.

Quando crei un nuovo repository "mio_repository" la prima volta che fai il sync dovresti passare il comando

```

paludis -s x-mio_repository

```

piuttosto che

```

paludis -s mio_repository

```

Questo vale solo per la prima volta.

Comunque sembra che a te stampi solo un messaggio di avvertimento, forse nelle ultime versioni non serve più anteporre "x-". Se leggi il messaggio, tra parentesi ti dice di ignorare l'avviso se è la prima volta che fai il sync.

Puoi settare il livello di verbosità di Paludis ussando la variabile di ambiente PALUDIS_OPTIONS che va inserita nel tuo file .bashrc. 

Quella variabile può contenere anche altri settaggi che tu consideri utili. Nel mio caso ad esempio:

```

export PALUDIS_OPTIONS="--log-level warning --dl-reinstall if-use-changed --show-use-descriptions changed --show-reasons summary"

```

 *flocchini wrote:*   

> 
> 
> domanda: come faccio a eliminare un overlay adesso? agisco sempre con layman e poi rigenero la cache di paludis giusto?

 

Layman funziona solo per Portage, almeno che non mi sbagli clamorosamente.

TUTTAVIA...  :Smile: 

Nella penultima release rilasciata ieri o l'altro ieri si legge questo:

 *News for Paludis - 0.26.0_alpha8 wrote:*   

> 
> 
> * Playman is now an "official" ruby demo script.
> 
> [...]
> ...

 

Questo significa che c'è un nuovo client che va a sostituire "layman". Io però non ho ancora avuto possibilità di provarlo.

```

$ ruby /usr/share/paludis/ruby/demos/playman.rb --help

Usage: /usr/share/paludis/ruby/demos/playman.rb [options] [overlay1] [overlay2] [...]

Options:

  --help, -h             Display a help message

  --version, -V          Display program version

  --log-level            Set log level (debug, qa, warning, slient)

  --environment, -E      Environment specification (class:suffix, both parts

                         optional, class must be 'paludis' if specified)

  --config-suffix, -c    Set configuration suffix (deprecated, use --environment)

  --list, -l             List available overlays.

  --add, -a              Add the given overlays.

  --no-names-cache       Disable the names cache for the added repos.

  --no-write-cache       Disable the write cache for the added repos.

Manages paludis configuration for layman overlays. Can add new overlays, and

list the currently available overlays from the global layman list.

If playman.tmpl exists in the Paludis repositories configuration directory, it

will be used as a template, with the strings @NAME@ and @SYNC@ replaced with

the name and sync URL of the overlay, respectively.  Otherwise, a builtin

default template will be used.

```

A occhio ti permette di aggiungere repositories ma non ancora rimuoverli  :Wink: 

Per eliminare un overlay basta che elimini il file relativo in /etc/paludis/repositories/ e cancelli la copia su disco. Poi in teoria dovrebbe bastare rigenerare la cache "installable"

```

paludis --regenerate-installable-cache

```

Altre info utili:

Repository ufficiale e overlay sono trattati tutti allo stesso modo.

I file di configurazione per i repositories si trovano in /etc/paludis/repositories/

```

$ ls /etc/paludis/repositories/

gentoo.conf  installed.conf  local.conf  paludis-overlay.conf

```

Io al momento ho 2 overlays, quello locale "local" e quello di paludis "paludis-overlay". Anche i pacchetti installati sono trattati come fossero un repository, infatti c'è "installed.conf" (dove setti alcune opzioni, tipo il metodo di caching, che riguarda i pacchetti installati).

Puoi impostare alcune opzioni di default per tutti i repository in /etc/paludis/repository_defaults.conf. Nel mio caso:

```

profiles = ${ROOT}/var/paludis/repositories/gentoo/profiles/default-linux/x86/2007.0/desktop

eclassdirs = /var/paludis/repositories/gentoo/eclass

distdir = ${ROOT}/var/paludis/repositories/gentoo/distfiles

```

Per come è impostata Gentoo al momento più o meno tutti gli overlay dipendono dal tree ufficiale (appunto perché sono overlay e non repositories a parte). Con quel file imposti delle proprietà comuni.

QUI c'è tutto quello che vuoi sapere sulla configurazione di Paludis. Ogni dettaglio  :Smile: [/code]

----------

## flocchini

ok, tnx, procediamo   :Cool: 

----------

## jordan83

Prova a dare

```

paludis -s x-portage

```

e così anche per gli altri repository che hai.

Forse anteporre "x-" serve ancora  :Smile: 

EDIT: riguardo eselect...

hai dato i comandi sbagliati (tipo "eselect read list").

Prova a dare

```

eselect news list

```

e poi

```

eselect news read xxxx

```

dove xxxx lo determini dal "list"  :Wink: 

----------

## flocchini

grazie per la dritta su eselect, mea culpa, mai usato prima  :Smile: 

per il problema sui 2 overlay nulla di risolto pero', continua a darmi l'errore. Ho spostato tutti gli overlay in /var/paludis/repositories e modificato opportunamente i conf, ho lasciato invece il portage in /usr/portage almeno sn sicuro di non fare troppi casini. Credo che il problema sui 2 overlay sia stato in fase di migrazione, infatti GUARDACASO sono gli unici 2 per i quali mi ha chiesto un nome, mentre ha fatto tutto in auto per zugaina, sabayon e gli altri.

Fatto sta che non c'e' sync che tenga, local e wschlich-testing non hanno sto maledetto repo_name che tra un po' gli creo a mano e buonanotte. Ma mi scoccia

----------

## jordan83

 *flocchini wrote:*   

> grazie per la dritta su eselect, mea culpa, mai usato prima 
> 
> per il problema sui 2 overlay nulla di risolto pero', continua a darmi l'errore. Ho spostato tutti gli overlay in /var/paludis/repositories e modificato opportunamente i conf, ho lasciato invece il portage in /usr/portage almeno sn sicuro di non fare troppi casini. Credo che il problema sui 2 overlay sia stato in fase di migrazione, infatti GUARDACASO sono gli unici 2 per i quali mi ha chiesto un nome, mentre ha fatto tutto in auto per zugaina, sabayon e gli altri.
> 
> Fatto sta che non c'e' sync che tenga, local e wschlich-testing non hanno sto maledetto repo_name che tra un po' gli creo a mano e buonanotte. Ma mi scoccia

 

Beh tutti i messaggi che ricevi sono QA e non warning. I messaggi QA indicano mancanze dal lato del servizio e non dell'utente.

In più non sono errori, bensì delle segnalazioni.

Ogni repository deve avere una cartella "profiles" con il seguente contenuto:

```

$ ls /var/paludis/repositories/local/profiles/

categories  repo_name  thirdpartymirrors

```

- categories contiene la lista delle categorie di pacchetti disponibili. Nel mio caso:

```

gio@localhost ~ $ cat /var/paludis/repositories/local/profiles/categories

app-portage

media-video

dev-util

dev-java

games-fps

gio@localhost ~ $ ls /var/paludis/repositories/local/

app-portage  dev-java  dev-util  games-fps  media-video  profiles

```

- repo_name nome del repository.

```

gio@localhost ~ $ cat /var/paludis/repositories/local/profiles/repo_name

local
```

- thirdpartymirrors una copia dello stesso file che trovi anche in portage (per recuperare i sorgenti)

Se queste componenti mancano Paludis riesce di solito ad assegnare dei valori di default o ignorare il problema. Però segnala la cosa.

Il repository "local" è responsabilità tua, quindi puoi andare a sistemarlo e aggiungere quello che ti manca.

Per quanto riguarda l'altro repository, non c'è nulla che tu possa fare, in quanto ad ogni sync le tue modifiche andrebbero perse.

Sono i gestori del repository che dovrebbero conformarlo agli standard  :Wink: 

Come vedi Paludis è piuttosto rigido e pretende qualità.

Se ti stufi degli avvisi QA basta che la tua variabile PALUDIS_OPTIONS contenga "--log-level warning".

----------

## flocchini

ok, ci siamo  :Smile:  aggiunto il repo_name a mano, paludis ha fatto il resto. Per local immaginavo che fosse "colpa" mia, cosi' come immaginavo che l'altro ebuild fosse fatto un po' a muzzo, l'importante e' capire come e perche': anche se i QA non sono importanti non posso non sapere perche' il mio package manager e' infelice  :Laughing:  Ho aggiunto anche io le tue opzioni al bashrc di paludis, in effetti di default mi sembrano utili

Ora ci smanetto un po', soprattutto voglio fare un po' di pulizia tra i pacchetti non utilizzati e le dipendenze orfane come facevo una volta con il compianto unclepine di xchris  :Wink: 

grazie del supporto, fino ad ora e per il futuro  :Smile: 

----------

## jordan83

 *flocchini wrote:*   

> 
> 
> Ora ci smanetto un po', soprattutto voglio fare un po' di pulizia tra i pacchetti non utilizzati e le dipendenze orfane come facevo una volta con il compianto unclepine di xchris 
> 
> 

 

Ti consiglio di dare un'occhiata alla documentazione nel sito.

Non è troppo vasta e in una decina minuti avrai una visione generale di Paludis, delle sue opzioni e delle possibilità che ti offre.

La sezione delle FAQ è importante. Dacci un'occhiata.

Tra l'altro ho appena visto che c'è una nuova sezione che riguarda i repository e la storia del "x-".  :Wink: 

 *flocchini wrote:*   

> 
> 
> grazie del supporto, fino ad ora e per il futuro 

 

Di nulla, figurati  :Wink: 

----------

## flocchini

si si sto finendo di spulciare tutto... Le FAQ hanno si' delle spiegazioni ma per capire come gira c'e' bisogno comunque di smanettarci. Non capisco ad esempio perche' una volta che tenta di nominarlo con x- non trovando di meglio, poi tutte le volte rompa le scatole... L'hai nominato con la x? E tieniti quel nome accidenti

cmq ho emerso (o ora si deve dire "paludato"?  :Laughing: ) un po' di pacchetti, fatto pulizia degli unused (che godimento   :Cool:   ) e fatto degli aggiornamenti... Per ora fila tutto liscio liscio, sono soddisfatto  :Smile: 

una sola cosa: mi e' capitato di leggere alla fine della compilazione "your action required", si riferisce ad etc-update vero? Che in effetti aveva da aggiornare e ha fatto il suo mestiere come al solito... Nella doc non ho ancora trovato traccia di questo passaggio

 *jordan83 wrote:*   

> 
> 
> temo di doverti deludere ma non mi pare che Paludis offra tali funzionalità.
> 
> Devi tenere conto che il progetto è giovane e comunque al momento ci sono altre priorità rispetto a funzioni "di contorno" (che comunque non dico non siano importanti).
> ...

 

sperando che di tempo ne sia passato abbastanza, domani mi dedichero' anche a questo  :Smile: 

----------

## jordan83

 *flocchini wrote:*   

> si si sto finendo di spulciare tutto... Le FAQ hanno si' delle spiegazioni ma per capire come gira c'e' bisogno comunque di smanettarci. Non capisco ad esempio perche' una volta che tenta di nominarlo con x- non trovando di meglio, poi tutte le volte rompa le scatole... L'hai nominato con la x? E tieniti quel nome accidenti
> 
> 

 

Paludis da un nome autogenerato giusto per risolvere il problema temporaneamente (visto che non è un problema "fondamentale") tuttavia non può soprassedere sulla cosa, perché non è in regola  :Smile: 

Deve rompere le balle, e anche bene, così noi utenti le rompiamo agli sviluppatori e loro correggono i loro bug...  :Mr. Green: 

 *flocchini wrote:*   

> 
> 
> una sola cosa: mi e' capitato di leggere alla fine della compilazione "your action required", si riferisce ad etc-update vero? Che in effetti aveva da aggiornare e ha fatto il suo mestiere come al solito... Nella doc non ho ancora trovato traccia di questo passaggio
> 
> 

 

Hai indovinato  :Wink: 

 *flocchini wrote:*   

> 
> 
>  *jordan83 wrote:*   
> 
> temo di doverti deludere ma non mi pare che Paludis offra tali funzionalità.
> ...

 

Da quel che ne so io non ci sono ancora cose equivalenti a "ufed" e "forcekeymask".

Di certo scrivere due utility così in python non dovrebbe essere difficilissimo.

In compenso parte di quello che fa "forcekeymask" lo puoi ottenere sfruttando lo switch

```

  --dl-override-masks    Zero or more mask kinds that can be overridden as necessary (default: tilde-keyword and license)

      none                 None (overrides defaults, not user selections)

      tilde-keyword        Keyword masks where accepting ~ would work

      unkeyworded          Keyword masks where a package is unkeyworded

      repository           Repository masks

      profile              Deprecated synonym for repository

      license              License masks

```

Ti elencherà i pacchetti che sono mascherati e bloccano l'installazione all'inizio dell'output, così sarà abbastanza facile aggiungerli a package_unmask.conf e/o keywords.conf

----------

## flocchini

mah... diciamo che sono un po' perplesso. Al di la' della sintassi e dei comandi volutamente (per non so quale motivo) diversificati da portage anche per le cose piu' banali, devo dire che e'  molto macchinoso, oltre che lento contrariamente alla sbandierata velocita'. Non discuto, sara' aderente a 47 standard diversi, flessibile e ordinato ma alla fine il vecchio portage mi manca un po' per semplicita' e immediatezza. Ho spulciato il forum e il sito, ho trovato tutto quello che mi serve ma c'e' qualcosa che mi impedisce di amarlo. Dipendenza a portage dopo 5 anni di gentoo? Puo' essere, gli do un'altra settimana di tempo e vediamo

----------

## jordan83

 *flocchini wrote:*   

> mah... diciamo che sono un po' perplesso. Al di la' della sintassi e dei comandi volutamente (per non so quale motivo) diversificati da portage anche per le cose piu' banali, devo dire che e'  molto macchinoso, oltre che lento contrariamente alla sbandierata velocita'. 
> 
> 

 

Per quanto riguarda la sintassi, certo è leggermente diversa da quella di Portage ma secondo me non è poi così difficile abituarsi.

Per quanto riguarda invece la velocità, devi tener conto del fatto che il collo di bottiglia è l'I/O. Ogni volta che Portage/Paludis fanno un calcolo delle dipendenze o una ricerca devono accedere a un numero enorme di file diversi.

Per ovviare a questa limitazione bisognerebbe cambiare il formato VDB e magari usare un database vero (o quanto meno sqlite) oppure si potrebbe creare una cache interamente contenuta in un file (come fa eix se non sbaglio) che potrebbe essere caricato velocemente in memoria.

Spero che in un futuro prossimo la cosa venga risolta...  :Wink: 

Comunque sia erano stati fatti dei test in passato e Paludis risulta essere un bel po' di volte più veloce di Portage (credo fosse tipo 6 volte più veloce). Per i motivi detti prima comunque è difficile fare di meglio... ^_^

 *flocchini wrote:*   

> 
> 
> Non discuto, sara' aderente a 47 standard diversi, flessibile e ordinato ma alla fine il vecchio portage mi manca un po' per semplicita' e immediatezza. Ho spulciato il forum e il sito, ho trovato tutto quello che mi serve ma c'e' qualcosa che mi impedisce di amarlo. Dipendenza a portage dopo 5 anni di gentoo? Puo' essere, gli do un'altra settimana di tempo e vediamo

 

Beh qui entriamo nel campo dei gusti personali...

Ognuno dovrebbe chiaramente scegliere secondo i parametri che più lo rendono felice  :Smile: 

----------

## Cazzantonio

Stavo provando anche io paludis e devo dire che concordo con fiocchini.

Trovo che la sua dinamica sia molto macchinosa... è vero che è più configurabile di portage, tuttavia certo non è pensato per essere immediato e subito funzionale (anche solo l'elevato numero di files di configurazione...).

Mentre portage è indirizzato a tutti i tipi di utenti (del terminale), trovo che paludis sia indirizzato soprattutto alla categoria dei programmatori smanettoni (e al loro gusto estetico).

Lo vedo soprattutto come un'ottima alternativa per chi ha davvero esigenze molto particolari... non per l'utilizzo di tutti i giorni (dove la macchinosità non è giustificata).

Mi domando... è necessario davvero stravolgere la struttura dei files di configurazione di portage? Non bastava una struttura simile a /etc/portage con dei files opzionali dove eventualmente inserire le features per-package con una sintassi nota?

Avevo provato paludis tempo addietro, e noto con disappunto che niente è cambiato da questo punto di vista. Ovviamente è una considerazione del tutto personale, tuttavia penso che se, anni addietro, gentoo avesse avuto paludis come packet manager avrei optato per un'altra distribuzione.

Ho dei problemi a descrivere praticamente cosa non mi piace perché è più una questione di feeling generale... trovo "quasi" esteticamente più soddisfacente apt (che pure è macchinoso).

Comunque è un po' più veloce, questo si, ma risente ancora della ENORME pecca di portage che è il suo gargantuesco albero da 252 mega. Se dovessi pensare ad un package manager diverso ne vorrei uno con un database di pacchetti più intelligente... E' ironico lavorare su una distro ottimizzandola e riducendola all'osso, e trovarsi ancora mezzo hard disk pieno dell'albero dei pacchetti... è moldo difficile far stare gentoo in meno di un giga...

Avanzo una proposta shock... e se le uniche informazioni da contenere nell'albero fossero le dipendenze e le use? In fondo quando faccio le ricerche sono le uniche cose importanti... tutto il resto dell'ebuild (le istruzioni su come compilarlo) potrebbe essere scaricato con il pacchetto stesso al momento dell'installazione...

Anche apt ha un albero di pacchetti, che contiene più o meno le stesse informazioni ma in modo molto più snello.

E' solo un'idea come un'altra, tuttavia in questo modo sarebbe fattibile un portage tree di dimensioni contenute (forse addirittura su un unico file, o su pochi file per ogni ramo dell'albero), una maggiore velocità di sync e un risparmio di banda, tempo e pazienza.

Sarebbe carino da proporre a qualche sviluppatore... anche solo per sentire la risata. Ne conoscete qualcuno?

----------

## jordan83

 *Cazzantonio wrote:*   

> Stavo provando anche io paludis e devo dire che concordo con fiocchini.
> 
> Trovo che la sua dinamica sia molto macchinosa... è vero che è più configurabile di portage, tuttavia certo non è pensato per essere immediato e subito funzionale (anche solo l'elevato numero di files di configurazione...).

 

Uhm... qua non sono d'accordo, visto che il numero credo sia lo stesso.

"In più" ci sono i file dei set (=funzionalità che portage non ha) e quelli dei repository/overlay, che comunque praticamente equivalgono in termini di caratteri ad aggiungere la riga in make.conf.

I nomi dei files saranno diversi (ma non dirmi che non capisci qual è l'equivalente di package.keywords o package.unmask...) ma spero che questo non sia un grosso problema.

Ho l'impressione che si accetti senza troppi problemi il dover andare incontro a una guida ad-hoc per l'upgrade di un pacchetto, tipo openssl, e non si accetta di leggere e interpretare il nome e l'uso di una decina di file una volta nella vita...  :Razz: 

 *Cazzantonio wrote:*   

> 
> 
> ...
> 
> 

 

Personalmente resto perplesso quando parlate di "macchinosità", in quanto non riesco bene a capire cosa intendiate  :Neutral: 

Se intendete messaggi di QA, warning e quant'altro dovreste riflettere se questo sia un problema di paludis o degli ebuild...

E non inquadro bene neanche quali possano essere le esigenze particolari per quali paludis sarebbe studiato, onestamente  :Smile: 

Per quanto concerne l'estetica, vorrei invitarti a riflettere sul fatto che Paludis è giovane e ci sono cose "core" che vanno implementate prima di questa.

Anch'io trovo che paludis --help non sia la cosa più bella da vedere per un nuovo utente, ad esempio. Tuttavia per certe "finezze" ci vuole tempo, al momento ci sono altre priorità, viste le risorse (=men power) limitate  :Wink: 

Portage è arrivato ad essere quello che è dopo anni in cui molti ci hanno lavorato sopra  :Smile: 

Il team di Paludis è più contenuto.

Le critiche sull'estetica sono giustissime, visto che l'usabilità è il fattore numero 1 per ogni software, tuttavia non trovo giusto farle proprio ora, visto che sarebbe come sparare sulla croce rossa  :Very Happy: 

E comunque Ciaran e soci accettano patch dai volonterosi, ovviamente se si conformano alle direttive di sviluppo.

 *Cazzantonio wrote:*   

> 
> 
> Ho dei problemi a descrivere praticamente cosa non mi piace perché è più una questione di feeling generale...
> 
> 

 

I problemi di feeling che tu stai sperimentando nell'uso di Paludis si risolvono solo col tempo (=un paio di settimane o di più, a seconda della persona).

Paludis non è Portage. Tornassi a portage ora, avrei lo stesso vostro problema (certo in forma minore essendo ex utente).

 *Cazzantonio wrote:*   

> 
> 
> Avanzo una proposta shock... e se le uniche informazioni da contenere nell'albero fossero le dipendenze e le use? In fondo quando faccio le ricerche sono le uniche cose importanti... tutto il resto dell'ebuild (le istruzioni su come compilarlo) potrebbe essere scaricato con il pacchetto stesso al momento dell'installazione...
> 
> Anche apt ha un albero di pacchetti, che contiene più o meno le stesse informazioni ma in modo molto più snello.
> ...

 

Personalmente mi trovi d'accordissimo, magari però terrei un file unico e non un albero di files...

Credo sia una cosa inaudita segare le gambe al package manager in questo modo...

Purtroppo Robbins è partito con questo approccio e ora non è facile cambiare.

Potresti lasciare un ticket a quelli di Paludis o un bug sul gestore dei bug di Portage. 

Al 90% credo che entrambi i team siano già coscenti del problema ma mentre secondo me quelli di Portage non osano provare a mettere le mani sul codice, quelli di Paludis un giorno (spero) decideranno di implementare qualcosa di più efficente.

----------

## Cazzantonio

 *jordan83 wrote:*   

> Le critiche sull'estetica sono giustissime, visto che l'usabilità è il fattore numero 1 per ogni software, tuttavia non trovo giusto farle proprio ora, visto che sarebbe come sparare sulla croce rossa 

 No anzi! Lo sto provando... in ogni caso sono proprio sensazioni a pelle. Quando il progetto avrà raggiunto una forma definitiva lo riproverò di nuovo.

 *Quote:*   

> Potresti lasciare un ticket a quelli di Paludis o un bug sul gestore dei bug di Portage. 
> 
> Al 90% credo che entrambi i team siano già coscenti del problema ma mentre secondo me quelli di Portage non osano provare a mettere le mani sul codice, quelli di Paludis un giorno (spero) decideranno di implementare qualcosa di più efficente.

 

Non penso non gli sia venuto in mente... e se non gli è venuto in mente allora c'è poco da fare.

----------

## cloc3

 *Cazzantonio wrote:*   

> 
> 
> Comunque è un po' più veloce, questo si, ma risente ancora della ENORME pecca di portage che è il suo gargantuesco albero da 252 mega.

 

un modo per escludere rami di portage esiste.

non credo che 252 mega siano un grosso numero ai tempi odierni.

e comunque lo è ogni giorno di meno.

il problema grosso, semmai, è il numero dei file e degli accessi al file system.

può essere che, addirittura, la tua idea finirebbe per aggravarlo, perché vuoi spezzare in due o più parti degli oggetti che, al momento, sono unitari.

forse non è un caso se D.Robbins, fin dalle prime versioni di gentoo, abbia spinto l'uso di file system alternativi (all'epoca i reiserfs erano particolarmente quotati) e tuttora abbia integrato i suoi vecchi articoli su funtoo.org, aggiornandoli pure.

naturalmente, se gli sviluppatori ti dessero ragione e puntassero ad una revisione delle tecnologie per i database benvenga, ma la mia percezione di profano rimpiangerebbe la perdita di un elemento estetico di semplicità. secondo me sono i file system a doversi adeguare, non portage.

----------

## jordan83

 *cloc3 wrote:*   

> 
> 
> naturalmente, se gli sviluppatori ti dessero ragione e puntassero ad una revisione delle tecnologie per i database benvenga, ma la mia percezione di profano rimpiangerebbe la perdita di un elemento estetico di semplicità. secondo me sono i file system a doversi adeguare, non portage.

 

Non ho nulla da obiettare sull'elemento estetico (ognuno ha i suoi gusti), di certo sono totalmente contro l'affermazione "sono i file system a doversi adeguare", l'ingegnere che c'è in me rabbrividisce  :Razz: 

È come dire che va bene inquinare perché è l'ambiente che deve arrangiarsi a migliorare e smaltire i nostri rifiuti.

Ognuno deve fare la sua parte sempre al meglio  :Wink: 

Oltre a questa questione di principio, migliorare i filesystem è pressoché inutile... Purtroppo finché non avremo harddisk veloci quanto un banco di ram ci sarà sempre il limite fisico a incidere molto di più di qualsiasi limite software.

E anche se avessimo harddisk ultraveloci, il principio esposto sopra mi vieta di considerare buona una soluzione che prevede un simile sperpero di risorse in termini di tempo (almeno per altri 3-4 anni  :Smile:  ), spazio e banda.

Eppure la soluzione secondo me sarebbe piuttosto semplice, dopo il post di Cazzantonio ci ho riflettuto un po' su.

Se fosse per me, farei così (anche se è un po' OT):

 :Idea:  Creerei un file XML Packages.xml (modello apt-get, anche se non è XML) che contiene le informazioni basilari sui pacchetti, necessarie per calcolo di dipendenze e info di base, quali:

- nome

- descrizione

- architetture supportate

- versioni

- disponibilità (mask, non mask)

- use flags e dipendenze

- qualche altro parametro che ora non ricordo, magari "peso" dei sorgenti da scaricare

 :Arrow:  Quando i developers aggiungono/tolgono/mascherano/modificano qualche pacchetto, questa lista va aggiornata di conseguenza (tool automatici possono farlo senza problemi).

 :Arrow:  Se Gentoo supporta N architetture, il server genera N pacchetti "sottolista" che contengono solo i pacchetti relativi alla data architettura, filtrando la roba inutile. Avremo quindi packages-x86.xml, packages-amd64.xml,... 

Semplicissimo e velocissimo da fare usando XSLT  :Wink: 

 :Arrow:  Quando un client si connette per il sync, comunica la sua architettura e il server gli invia il "diff" della sottolista prescelta (immagino pochi KB).

 :Arrow:  Una volta scaricata la lista, questa magari può essere importata in un database locale che funge da cache, usata così com'è o trasformata in qualche altro modo (magari trasformata e ottimizzata secondo le use flags dell'utente, così altri dati "inutili" possono essere messi da parte anche se magari non eliminati)... 

in ogni caso la cosa sarebbe velocissima, visto che è XML ed è facile da manipolare --ergo--> sync effettuato in 3 secondi netti (vabbé esagero mi sa  :Very Happy:  ).

 :Arrow:  Quando si vuole installare un pacchetto, il package manager scarica sorgenti + ebuild e fa il suo sporco lavoro.

 :Idea:   Le informazioni sui pacchetti installati io le salverei in un db sqlite (non ha senso secondo me usare qualcosa tipo mysql, ma magari lo si potrebbe lasciare opzionale) --ergo--> calcolo delle dipendenze e moltissime altre operazioni "costose" diventerebbero pressoché immediate (o quasi insomma, di certo scommetto non più di 5 secondi coi pc attuali).

 :Arrow:  Spazio occupato dal "tree"... 500Kb?  :Smile: 

Gli ebuild verrebbero scaricati solo quando sarebbe necessario.

Io farei così. Se avessi un po' di tempo mi metterei al lavoro, di certo non dovrebbe essere impossibile  :Wink: 

In Paludis la cosa dovrebbe risultare piuttosto fattibile.

Purtroppo (o per fortuna  :Smile:  ) al momento sto lavorando sulla mia tesi e su un altro paio di applicazioni, ergo mi è impossibile aggiungere altro  :Neutral: 

Ma magari dopo settembre...  :Wink: 

----------

## cloc3

 *jordan83 wrote:*   

> (anche se è un po' OT):
> 
>  Creerei un file XML Packages.xml

 

ci splittino i mod se lo ritengono.

a quanto pare hai le idee chiare.

bisognerebbe però tenere conto anche dell'usabilità.

l'utente che desidera modificare un pacchetto, creandosi il proprio overlay,

dovrebbe poi mettere le mani dentro il database?

continuerà a lavorare con gli editor di testo o dovrà appoggiarsi ad un tool apposito?

e se semplicemente desiderasse studiare un ebuild, dovrebbe prima scaricarsi il codice sorgente?

e si potrebbe ancora navigare la $PORTDIR per cercare nuovi pacchetti sconosciuti?

----------

## Cazzantonio

[quote="jordan83"] *cloc3 wrote:*   

> Ma magari dopo settembre... 

 Hei voglio i diritti sull'idea!   :Laughing: 

Scherzo.... comunque se avrai bisogno sono disposto a darti mano...

----------

## jordan83

 *cloc3 wrote:*   

> 
> 
> bisognerebbe però tenere conto anche dell'usabilità.

 

Beh certo. Le idee espresse sopra erano per "sommi capi"  :Smile: 

 *cloc3 wrote:*   

> 
> 
> l'utente che desidera modificare un pacchetto, creandosi il proprio overlay,
> 
> dovrebbe poi mettere le mani dentro il database?

 

In linea di massima il database esisterebbe solo per i pacchetti installati e andrebbe a sostituire /var/db/pkg (l'attuale "database"  :Neutral:  ).

Dubito che qualcuno ci abbia mai messo le mani, di solito lo usa solo il pm.

Anche se si decidesse di trasferire il contenuto del file packages.xml in un database sqlite per velocizzare le cose comunque, l'utente dovrebbe avere a che fare sempre e solo con il file XML packages.xml. Poi magari il database potrebbe essere autogenerato una volta che il file XML è pronto.

Per il tuo repository locale dovresti editare il file packages.xml per aggiungere un pacchetto o magari usare un tool che ti semplifichi la vita e ti eviti di scrivere xml puro.

Ancora meglio: un tool che faccia il parsing dell'header dell'ebuild, crei l'elemento XML e lo aggiunga al file..  :Wink: 

In pratica un repository/overlay locale funzionerebbe come sempre. 

L'unica cosa in più da fare é mantenere il file packages.xml aggiornato allo stato del repository, o i pacchetti non verrebbero visti dal pm.

Per fare ció in scioltezza basterebbe un demone/comando ad-hoc. Ad esempio

```

repomaster --update-list

```

Tutto qua.

Per repository grandi (tipo quello di Gentoo) la soluzione demone mi sembra la migliore. Scansionerebbe il tree ogni 5 minuti e aggiornerebbe la lista. Altra soluzione potrebbe essere un hook ad-hoc che si attivi ad ogni commit in SVN.

 *cloc3 wrote:*   

> 
> 
> continuerà a lavorare con gli editor di testo o dovrà appoggiarsi ad un tool apposito?

 

Tutto resterebbe come prima per quanto riguarda gli ebuild. L'unica differenza é che bisogna mantenere la lista"packages.xml" aggiornata, cosa che comunque come detto sopra puó essere fatta in modo "trasparente" (=praticamente nessun intervento manuale richiesto).

 *cloc3 wrote:*   

> 
> 
> e se semplicemente desiderasse studiare un ebuild, dovrebbe prima scaricarsi il codice sorgente?

 

Direi di no, una cosa cosí potrebbe andare bene

```

repomaster --get-ebuild pacchetto-1.2.3

```

Al limite i piú smanettoni o curiosi potrebbero addirittura tenersi una copia locale di tutti gli ebuild, ad esempio con

```

repomaster --get-tree

```

oppure 

```

paludis --sync-tree

```

In pratica ti beccheresti sul tuo hard disk i 250MB attuali, ma saresti tu a sceglierlo però  :Smile: 

 *cloc3 wrote:*   

> 
> 
> e si potrebbe ancora navigare la $PORTDIR per cercare nuovi pacchetti sconosciuti?

 

Di certo non avresti gli ebuild sul tuo HD, tuttavia puoi sempre fare un giro in internet o creare/consultare un sito del tipo www.unebuildalgiorno.it

Se proprio fossi desideroso di ravanare tra gli ebuild sul tuo HD basterebbe che ti scaricassi il tree come detto sopra.

In pratica questa soluzione si affianca a quella già esistente e di certo non limita le possibilità dell'utente, bensì le amplia...

In questo modo si farebbero contente molte più persone.

Ci sarebbe chi ogni giorno darebbe un bel

```

paludis --sync

```

e si aggiornerebbe solo i files packages.xml e chi invece darebbe un bel

```

paludis --sync-tree

```

e si aggiornerebbe i files packages.xml e magari si otterrebbe una copia in locale di tutti gli ebuild  :Wink: 

E comunque sia, per entrambe le tipologie di utenti, i benefici in termini di prestazioni sarebbero enormi (di certo non si andrebbe in peggio rispetto a ora...).

Non sembra male a me  :Smile: 

 *Cazzantonio wrote:*   

> Hei voglio i diritti sull'idea!   

 

Beh, ovvio, non l'avevo esplicitato ma era incluso in  *jordan83 wrote:*   

> ...dopo il post di Cazzantonio ...

   :Razz: 

 *Cazzantonio wrote:*   

> Scherzo.... comunque se avrai bisogno sono disposto a darti mano...

 

Ci conto  :Smile: 

----------

## Cazzantonio

 *cloc3 wrote:*   

> bisognerebbe però tenere conto anche dell'usabilità.

 Infatti secondo me bisognerebbe continuare ad utilizzare normali file di testo. Sono facilmente accessibili e modificabili, in oltre non è un problema manipolarli tramite tools appositi. Non ho mai capito il vero vantaggio dei file xml...

 *Quote:*   

> e se semplicemente desiderasse studiare un ebuild, dovrebbe prima scaricarsi il codice sorgente?

 Perché no? Basta un fetch... mica uno controlla tutti gli ebuild che installa... è solo una cosa da fare sporadicamente.

 *Quote:*   

> e si potrebbe ancora navigare la $PORTDIR per cercare nuovi pacchetti sconosciuti?

 Non cambierebbe nulla. Avresti ancora in locale l'elenco dei pacchetti con tanto di descrizione, solo dovresti scaricare ogni volta l'ebuild con le struzioni per l'installazione.

@jordan83

Vedo che hai già proposto cose tipo database sqlite et similia. Io cercherei di mantenere al minimo le dipendenze. Un gestore di pacchetti dovrebbe dipendere dal minimo di librerie possibile e da possibilmente nessun comando esterno. In questo senso apprezzo paludis che dipende solo dalle glibc (presenti di default in un sistema linux differentemente dal python).

----------

## jordan83

 *Cazzantonio wrote:*   

> Infatti secondo me bisognerebbe continuare ad utilizzare normali file di testo. Sono facilmente accessibili e modificabili, in oltre non è un problema manipolarli tramite tools appositi. Non ho mai capito il vero vantaggio dei file xml...

 

I file XML hanno il vantaggio di definire nel documento una chiara struttura e quindi è facile accedere alle informazioni che contengono, non ché controllarne la validità.

Scrivere un parser che estragga informazioni dal file XML è semplice ed è possbile farlo da praticamente qualsiasi linguaggio di programmazione.

 *Cazzantonio wrote:*   

> 
> 
> @jordan83
> 
> Vedo che hai già proposto cose tipo database sqlite et similia. Io cercherei di mantenere al minimo le dipendenze. Un gestore di pacchetti dovrebbe dipendere dal minimo di librerie possibile e da possibilmente nessun comando esterno. In questo senso apprezzo paludis che dipende solo dalle glibc (presenti di default in un sistema linux differentemente dal python).

 

Hai perfettamente ragione in effetti.

Probabilmente potrebbe bastare salvare la lista dei pacchetti installati in un file di testo o in un file XML.

Certo che da questo punto di vista anche l'uso di XML potrebbe essere limitante, visto che comunque servirebbe una libreria XML a disposizione  :Neutral: 

Non so, in effetti bisognerebbe pensare bene alle scelte da fare.

Probabilmente hai ragione te e conviene fare tutto basandosi su semplici file di testo come fa dpkg, che già è velocissimo  :Wink: 

----------

## Cazzantonio

Ci ho pensato un po' su e la cosa non mi pare terribilmente difficile. In realtà è possibile implementare tutto questo senza rinunciare alla retrocompatibilità con l'attuale sistema di portage...

Basta una variabile in make.conf, che se impostata configura il nuovo modello di albero:

1) Per garantire la retrocompatibilità basta utilizzare lo stesso formato degli attuali ebuild. La prima parte contiene già le informazioni necessarie su dipendenze, use, descrizione etc... Basta semplicemente istruire portage (o paludis) di andare a cercarsi le stesse informazioni in un unico file (o un solo file per ogni categoria, oppure un database, un xml...). L'importante è che siano strutturate nello stesso modo e che l'implementazione conservi i nomi delle variabili.

In pratica basterebbe una piccola modifica alle funzioni di ricerca e basta (cambia il "dove" e non il "come").

L'utente dovrebbe essere ancora in grado di accedere a queste informazioni, leggerle e modificarle semplicemente se necessario.

2) Quando arriva il momento dell'installazione vera e propria il packet manager scarica tutto l'ebuild (insieme al pacchetto), lo salva in /var/db/pkg/ e lo usa per installare il pacchetto. Anche qui una minuscola modifica alle funzioni di fetch e di installazione, ma niente di fondamentale.

3) Anche la gestione di un overlay locale non cambia. In questo caso si applica il vecchio metodo di installazione con tutto l'ebuild (invece della sola prima parte con le info).

4) In un secondo momento uno può pensare a trasformare /var/db/pkg/ in un database, visto che comunque sono informazioni sui pacchetti installati che un utente non dovrebbe modificare con leggerezza.

Quando si parla di database secondo me è importante pensare ad una soluzione semplice, con il minor numero di dipendenze possibile e addirittura da integrare nello stesso packet manager. Altrimenti meglio usare file di testo semplici, con buona pace dell'efficienza.

----------

## lucapost

Ho letto con interesse gli ultimi sviluppi di questo thread.

L'idea di gestire le informazioni (dipendenze, use, descrizione etc...) che non riguardano l'installazione attraverso un xml o simili mi sembra buona.

Ma l'idea di dover successivamente scaricare un ebuild (che nella forma attuale) contiene nuovamente tali informazioni non mi piace proprio. Questa ridondanza, IMHO, dovrebbe essere  eliminanta

----------

## Cazzantonio

 *lucapost wrote:*   

> Questa ridondanza, IMHO, dovrebbe essere  eliminanta

 Sono solo pochi kilobytes per ogni ebuild, forse meno, in ogni caso potresti risparmiare solo la parte iniziale che contiene le info sul pacchetto (IUSE, DEPENS etc...), quindi il risparmio non vale la potenziale difficoltà di implementazione. In ogni caso è utile perché consentirebbe di garantire una retrocompatibilità.

Niente vieta poi, in un eventuale lontano futuro, di eliminare la retrocompatibilità ed eliminare quei pochi bytes in più dall'ebuild.

L'unico problema vero potrebbero essere eventuali discordanze tra l'ebuild scaricato e il database dei pacchetti in locale. Questo richiederebbe effettivamente un minimo di pianificazione. In questo caso bisognerebbe che il programma avvertisse l'utente di risincronizzare il database locale, oppure che lo avvertisse degli eventuali cambiamenti. Non sono infrequenti dei cambi delle use negli ebuild... Ci vorrebbe una politica che obblighi gli sviluppatori a modificare anche la versione dell'ebuild quando viene aggiunta/tolta una use o fatta una qualsiasi modifica all'ebuild, cosa che sarebbe sensata anche nella situazione attuale.

----------

## jordan83

 *Cazzantonio wrote:*   

>  *lucapost wrote:*   Questa ridondanza, IMHO, dovrebbe essere  eliminanta Sono solo pochi kilobytes per ogni ebuild, forse meno, in ogni caso potresti risparmiare solo la parte iniziale che contiene le info sul pacchetto (IUSE, DEPENS etc...), quindi il risparmio non vale la potenziale difficoltà di implementazione. In ogni caso è utile perché consentirebbe di garantire una retrocompatibilità.
> 
> Niente vieta poi, in un eventuale lontano futuro, di eliminare la retrocompatibilità ed eliminare quei pochi bytes in più dall'ebuild.
> 
> 

 

Concordo su quanto detto da Cazzantonio.

Sarebbe certo bello rivisitare l'intero concetto di tree, ebuild e annessi/connessi, in quanto molte cose potrebbero essere migliorate.

Tuttavia se si vuole ottenere il massimo col minimo impatto bisogna pensare alla retrocompatibilità  :Wink: 

 *Cazzantonio wrote:*   

> 
> 
> L'unico problema vero potrebbero essere eventuali discordanze tra l'ebuild scaricato e il database dei pacchetti in locale. Questo richiederebbe effettivamente un minimo di pianificazione. In questo caso bisognerebbe che il programma avvertisse l'utente di risincronizzare il database locale, oppure che lo avvertisse degli eventuali cambiamenti. Non sono infrequenti dei cambi delle use negli ebuild... Ci vorrebbe una politica che obblighi gli sviluppatori a modificare anche la versione dell'ebuild quando viene aggiunta/tolta una use o fatta una qualsiasi modifica all'ebuild, cosa che sarebbe sensata anche nella situazione attuale.

 

Beh ma gli ebuild cambiano versione quando vengono modificati; la parte "-rx" se non erro serve anche a questo  :Wink: 

E comunque, come suggerivo in un post precedente, basterebbe un hook in svn o un demone automatico che aggiornasse la lista ad ogni commit.

Trovare una soluzione a questo problema comunque non dovrebbe essere difficile  :Wink: 

----------

## Cazzantonio

 *jordan83 wrote:*   

> Beh ma gli ebuild cambiano versione quando vengono modificati; la parte "-rx" se non erro serve anche a questo 

 Non sempre... a volte capita di trovarsi degli ebuild da ricompilare solo perché è cambiata una use flag (emerge -vdUN world... non te ne sei accorto perché paludis non fornisce giustamente l'opzione "-N"...), pure se non è stata cambiata la versione -rx dell'ebuild.

Si tratta in ogni caso di una politica evidentemente scorretta...

----------

## jordan83

 *Cazzantonio wrote:*   

> non te ne sei accorto perché paludis non fornisce giustamente l'opzione "-N"...

 

```

--dl-reinstall

    When to reinstall packages

    never

        Never (default)

    always

        Always

    if-use-changed

        If USE flags have changed

```

dipende se inserisci o meno "--dl-reinstall if-use-changed" in PALUDIS_OPTIONS  :Wink: 

----------

## jordan83

Vorrei segnalare questa intervista (in inglese) a Ciaran McCreesh, lo sviluppatore principale di Paludis.

L'ho trovata per caso e secondo me vale la pena di leggerla.

Uno sguardo al passato/presente/futuro di Paludis e Gentoo  :Smile: 

----------

## jordan83

Sembra che qualcosa si muova verso l'implementazione di un nuovo db in sostituzione dell'azzoppante VDB...

```

    * rsync based syncers (rsync://, file://, tar+http:// and tar+ftp://) now

      support --exclude in sync_options, as well as --exclude-from.

    * Set names are now supported in package_mask.conf and package_unmask.conf.

    * Experimental new Exndbam repository, which can replace VDB on systems that

      don't use Gentoo trees.

    * In various places we now sort by i-node rather than filename when doing

      directory recursion. This gives substantial i/o improvements.

```

Non c'è traccia nella documentazione o in qualsiasi altro luogo di questa cosa quindi è davvero sperimentale e agli inizi.

In più con "on systems that don't use Gentoo trees" credo intendano sistemi che usano "exheres" la nuova versione degli ebuild ("ebuilds redesigned with ten years of experience" per quotare la definizione riportata nell'intervista che avevo segnalato nel post precedente).

Certo questa è solo una mia supposizione. Potrebbe anche voler semplicemente dire che usando questo formato si romperebbe la compatibilità con Portage.

Finalmente una ventata di freschezza all'orizzonte  :Smile: 

----------

## beso_1717

can someone indicate how to surpass instruo's following error message:

```
Unhandled exception:

  * In program instruo -g --repository-dir /var/paludis/repositories/paludis-overlay/ -o /var/cache/paludis/metadata/paludis-overlay/:

  * When loading profiles.desc:

  * E Repository configuration error: No profiles.desc found (paludis::ERepositoryConfigurationError)

```

i get this on every repository. i haven't tried in on gentoo overlay since it already has its own metadata included into update, but all the other repos give this error. i tried to manually regenerate the metadata for some overlays that have failed to generate it during sync (i use the hook of metadata generation) and it fails on some repos.

also another question is the following:

i get a warning of missing virtual/php, but i cannot the package that triggers this warning to recompile it (openrc should handle the absence of virtuals).

another question is regarding baselayout package:

i've tried to build it with paludis a lot of times but if not using collision-proteck and config-protect variable paludis makes my system unbootable because in the cleanup phase it removes some baselayout files. also in the case of upgrading from baselayout-1 to baselayout-2 i had to manually install openrc since it hasn't been triggered by paludis dep-graph. i don't know if others have experienced this issue but i think that isn't quite ok.

the last question is:

wine always spits out the error of libsandbox.so cannot be preloaded, but it compiles nevertheless (i've disabled sandbox for this package as for some other packages) is this normal or it's my system that has something weird?! i think that i have a lot of permissions problems since i get a lot of permissions error here and there, but i don't really have the time to look into this matter and since the system, for the moment works, it isn't very important, but i still have issues like external disks (not usb sticks) not being writable by normal user, even when mounted with the user itself via hald, or the fact that udf dvds aren't readable by the user that has mounted them but are fully functional from root, or even the fact that i cannot run emerging from paludisbuild user, but only via root suid. i'd really like some help if someone does know something on the matter.

but the important thing is the instruo one.

----------

## jordan83

 *beso_1717 wrote:*   

> can someone indicate how to surpass instruo's following error message:
> 
> ```
> Unhandled exception:
> 
> ...

 

Well, the output is quite clear, paludis cannot find the profiles.desc file... That file is provided by the gentoo repository.

But you don't have to regenerate the metadata... I think you are mistaking metadata for cache.

Metadata is not "generated" or "regenerated", but it is just downloaded from the repository when you perform a sync.

If you have a look inside the directory you see what it contains:

```

$ ls /var/paludis/repositories/gentoo/metadata/

cache  dtd  glsa  herds.xml  news  timestamp  timestamp.chk  timestamp.x

```

Just think... how are you supposed to generate glsa ("gentoo linux security advisories") automatically??!  :Smile: 

If you want to regenerate the cache data just type:

```

paludis --regenerate-installable-cache

```

but usually you don't need to run this command.

 *beso_1717 wrote:*   

> 
> 
> openrc [...]
> 
> baselayout [...]
> ...

 

I don't use the masked versions of those packages yet, thus I cannot help you out here. Besides your description is a bit vague. Try to be a bit more specific and maybe post these questions in the official Paludis english thread  :Wink: 

 *beso_1717 wrote:*   

> 
> 
> the last question is:
> 
> wine always spits out the error of libsandbox.so cannot be preloaded, but it compiles nevertheless (i've disabled sandbox for this package as for some other packages) is this normal or it's my system that has something weird?!
> ...

 

Uhm... Maybe you have some inconsistencies. Try to run reconcilio to see if that's the case.

 *beso_1717 wrote:*   

> 
> 
>  i think that i have a lot of permissions problems since i get a lot of permissions error here and there, but i don't really have the time to look into this matter and since the system, for the moment works, it isn't very important, but i still have issues like external disks (not usb sticks) not being writable by normal user, even when mounted with the user itself via hald, or the fact that udf dvds aren't readable by the user that has mounted them but are fully functional from root,
> 
> 

 

Is the user member of the plugdev group?

Have a look on the official documentation, gentoo-wiki.org and past posts. These issues are very common  :Wink: 

 *beso_1717 wrote:*   

> 
> 
>  or even the fact that i cannot run emerging from paludisbuild user, but only via root suid. 

 

You are not supposed to login with paludisbuild whenever you install a package! 

The paludisbuild account is meant to be used by paludis only, so that it can drop from root permissions to common-user permissions whenever the former are too high considered the task being performed. 

For example when you compile you don't need root privileges, whilst when you install files in / you need them. 

It's one of the basic and most important laws in security.

We are glad to have you here in the italian forum but certainly the best place to ask questions in english is the official Paludis english thread  :Smile: 

----------

## beso_1717

 *jordan83 wrote:*   

> 
> 
>  *beso_1717 wrote:*   
> 
> the last question is:
> ...

 

no il problema è proprio solo di questo package specifico. tutti gli altri che hanno sandbox disabilitato non fanno questo scherzo. non capisco perche mi capita. eseguo reconcilio ogni volta che vado a riaggiornare il world per tenere sempre il sistema consistente. 

 *Quote:*   

> 
> 
>  *beso_1717 wrote:*   
> 
>  i think that i have a lot of permissions problems since i get a lot of permissions error here and there, but i don't really have the time to look into this matter and since the system, for the moment works, it isn't very important, but i still have issues like external disks (not usb sticks) not being writable by normal user, even when mounted with the user itself via hald, or the fact that udf dvds aren't readable by the user that has mounted them but are fully functional from root,
> ...

 

controllato e ricontrollato più e più volte e le impostazioni sono esattamente come quelle suggerite. ho anche provato a rimuovere udev dbus e hal e le variabili di configurazione da /etc riaggiornare l'environment e poi reinstallare udev, dbus e hal per vedere cosa succedesse ma niente: stesso problema.

ma questo non è legato a paludis per cui non è importante. ormai mi sono messo l'anima in pace.

 *Quote:*   

> 
> 
>  *beso_1717 wrote:*   
> 
>  or even the fact that i cannot run emerging from paludisbuild user, but only via root suid.  
> ...

 

questo appunto è il problema. paludis esegue tutte le operazioni come root. e questo non dovrebbe accadere. portage  funziona normalmente ma paludis esegue sia compilazione sia fetch con root. questo ovviamente provoca non pochi problemi e soprattutto mi rende incapace di usare paludis se non da root shell. ho provato a riaggiustare i privileggi a mano ma l'unica utilità è stata quella di doverli riassegnare complettamente a root perche paludis si era incartata.

per la storia dell'inglese, scusate, ma era mezzo rinco a lavoro mentre scrivevo e mi sembra di essere nel forum inglese.

----------

## jordan83

 *beso_1717 wrote:*   

> 
> 
> no il problema è proprio solo di questo package specifico. tutti gli altri che hanno sandbox disabilitato non fanno questo scherzo. non capisco perche mi capita. eseguo reconcilio ogni volta che vado a riaggiornare il world per tenere sempre il sistema consistente. 
> 
> 

 

Uhm... a me non da questo errore.

Ma cosa intendi con "sandbox disabilitato"? Paludis mantiene il sandbox sempre attivato, non so se lo puoi disattivare.

Che versioni usi? Hai un sistema ~x86?

Male che vada se raccogli un po' di output puoi provare a postare un bug report.

 *beso_1717 wrote:*   

> 
> 
> questo appunto è il problema. paludis esegue tutte le operazioni come root. e questo non dovrebbe accadere. portage  funziona normalmente ma paludis esegue sia compilazione sia fetch con root. questo ovviamente provoca non pochi problemi e soprattutto mi rende incapace di usare paludis se non da root shell. ho provato a riaggiustare i privileggi a mano ma l'unica utilità è stata quella di doverli riassegnare complettamente a root perche paludis si era incartata.
> 
> 

 

Può essere che la cartella "distfiles" abbia dei permessi sbagliati, così come magari /var/tmp/paludis.

```

$ ls -l /var/tmp/ | grep paludis

drwsrwsr-x  3 root    paludisbuild 4096 2008-05-10 13:04 paludis

```

```

$ ls -l /var/paludis/repositories/gentoo/ | grep distfiles

drwxrwsr-x   4 paludisbuild paludisbuild 69632 2008-05-10 12:40 distfiles

```

Se non ricordo male nel caso paludis non riesca a scrivere o leggere in una cartella lascia perdere la storia di "paludisbuild" e fa tutto da root (dopo aver sparato qualche sorta di avvertimento o errore).

----------

## beso_1717

 *jordan83 wrote:*   

>  *beso_1717 wrote:*   
> 
> no il problema è proprio solo di questo package specifico. tutti gli altri che hanno sandbox disabilitato non fanno questo scherzo. non capisco perche mi capita. eseguo reconcilio ogni volta che vado a riaggiornare il world per tenere sempre il sistema consistente. 
> 
>  
> ...

 

sempre solamente: libsandbox.so.1 cannot be preloaded non ho compilato le funzioni di debug quindi non so dire di piu. sono su ~amd64.

 *Quote:*   

> 
> 
>  *beso_1717 wrote:*   
> 
> questo appunto è il problema. paludis esegue tutte le operazioni come root. e questo non dovrebbe accadere. portage  funziona normalmente ma paludis esegue sia compilazione sia fetch con root. questo ovviamente provoca non pochi problemi e soprattutto mi rende incapace di usare paludis se non da root shell. ho provato a riaggiustare i privileggi a mano ma l'unica utilità è stata quella di doverli riassegnare complettamente a root perche paludis si era incartata.
> ...

 

infatti è quello che sta facendo e mi da parecchio fastidio avere sia la fase di fetch che di build come root. le mie directory sono uguali ma il temp ha permessi paludisbuild:paludisbuild. invece di root:paludisbuild.  provarò con i tuoi e vedo se cambia qsa. 

per caso ti capita di ricevere l'avvertimento che manca dev-lang/php 5.2.6?! io continuo a prendere questo avvertimento da quando sono passato a php-5.2.6-r1. mi pare strano che spunti fuori sempre anche dopo avere ricompilato i pacchetti che davano il warning.

----------

## jordan83

 *beso_1717 wrote:*   

> 
> 
> sempre solamente: libsandbox.so.1 cannot be preloaded non ho compilato le funzioni di debug quindi non so dire di piu. sono su ~amd64.
> 
> 

 

Mi sa che sei caduto in un caso di "sandbox violation"... da quello che dicono nelle FAQ questo dovrebbe essere un problema specifico del pacchetto e non di paludis.

In questo thread mi pare abbiano avuto un problema simile al tuo.

Non credo ci sia nulla di cui tu debba preoccuparti quindi, benché il fatto di dover disabilitare la sandbox in sé non sia proprio un bene... 

Credo che questo possa essere considerato a tutti gli effetti un bug dell'ebuild  :Wink: 

 *beso_1717 wrote:*   

> 
> 
> per caso ti capita di ricevere l'avvertimento che manca dev-lang/php 5.2.6?! io continuo a prendere questo avvertimento da quando sono passato a php-5.2.6-r1. mi pare strano che spunti fuori sempre anche dopo avere ricompilato i pacchetti che davano il warning.

 

Uhm, io non uso la versione mascherata.

"Può essere" che i pacchetti riportati nell'errore richiedano la specifica versione 5.2.6, in tal caso il problema è dell'ebuild. Potresti dare un'occhiata.

Casomai prova a copiare/incollare l'errore  :Wink: 

----------

## 102376

mi sono perso un attimo con paludis volevo provare ad aggiornare. mi da un po' di warinig e mi dice che vuole fare il downgrade chi mi aiuta a capire:

```
paludis --pretend --install --dl-downgrade warning world

Building target list...

Building dependency list...paludis@1211573785: [QA version_spec.too_long] In program paludis --pretend --install--dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding NamedSetDepSpec 'system':

  ... When adding PackageDepSpec 'sys-apps/net-tools':

  ... When fetching versions of 'sys-apps/net-tools' in gentoo:

  ... When loading versions for 'sys-apps/net-tools' in gentoo:

  ... When creating ID for 'sys-apps/net-tools' from '/usr/portage/sys-apps/net-tools/net-tools-1.60_p20071202044231-r1.ebuild':

  ... When extracting version from '/usr/portage/sys-apps/net-tools/net-tools-1.60_p20071202044231-r1.ebuild':

  ... When parsing version spec '1.60_p20071202044231-r1':

  ... Number part '20071202044231' exceeds 8 digit limit permitted by the Package Manager Specification (Paludissupports arbitrary lengths, but other package managers do not)

paludis@1211573786: [WARNING dep_list.downgrade] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'app-emulation/virtualbox-bin':

  ... When adding installed package 'app-emulation/virtualbox-bin-1.5.6:0::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '~app-emulation/virtualbox-modules-1.5.6':

  ... Downgrade to 'app-emulation/virtualbox-modules-1.5.6:0::gentoo' from 'app-emulation/virtualbox-modules-1.5.7:0::installed' forced

paludis@1211573787: [WARNING dep_list.ignoring_dependencies] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'app-text/kchmviewer':

  ... When adding installed package 'app-text/kchmviewer-3.1_p2:0::installed':

  ... Ignoring run dependencies due to exception 'Error searching for 'app-doc/chmlib': no available versions' (paludis::AllMaskedError)

paludis@1211573787: [QA version_spec.too_long] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'kde-base/kde-meta':

  ... When adding installed package 'kde-base/kde-meta-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=kde-base/kdeadmin-meta-4.0.4:kde-4':

  ... When adding installed package 'kde-base/kdeadmin-meta-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=kde-base/kcron-4.0.4:kde-4':

  ... When adding installed package 'kde-base/kcron-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=kde-base/knotify-4.0.4:kde-4':

  ... When adding installed package 'kde-base/knotify-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=kde-base/phonon-4.0.4:kde-4':

  ... When adding installed package 'kde-base/phonon-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=media-libs/xine-lib-1.1.9':

  ... When fetching versions of 'media-libs/xine-lib' in zugaina:

  ... When loading versions for 'media-libs/xine-lib' in zugaina:

  ... When creating ID for 'media-libs/xine-lib' from '/usr/portage/local/layman/zugaina/media-libs/xine-lib/xine-lib-999999999999.ebuild':

  ... When extracting version from '/usr/portage/local/layman/zugaina/media-libs/xine-lib/xine-lib-999999999999.ebuild':

  ... When parsing version spec '999999999999':

  ... Number part '999999999999' exceeds 8 digit limit permitted by the Package Manager Specification (Paludis supports arbitrary lengths, but other package managers do not)

paludis@1211573790: [QA version_spec.too_long] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'media-video/ksubtile':

  ... When adding installed package 'media-video/ksubtile-1.2:0::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec 'media-video/mplayer':

  ... When fetching versions of 'media-video/mplayer' in zugaina:

  ... When loading versions for 'media-video/mplayer' in zugaina:

  ... When creating ID for 'media-video/mplayer' from '/usr/portage/local/layman/zugaina/media-video/mplayer/mplayer-999999999-r7.ebuild':

  ... When extracting version from '/usr/portage/local/layman/zugaina/media-video/mplayer/mplayer-999999999-r7.ebuild':

  ... When parsing version spec '999999999-r7':

  ... Number part '999999999' exceeds 8 digit limit permitted by the Package Manager Specification (Paludis supports arbitrary lengths, but other package managers do not)

paludis@1211573791: [WARNING dep_list.downgrade] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'net-im/skype':

  ... When adding installed package 'net-im/skype-2.0.0.68:0::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec 'x11-libs/qt[=4.4.0_beta1|=4.4.0_rc1|=4.3.4-r1|=4.3.4|=4.3.3|=4.3.2-r1|=4.3.2|=4.3.1-r1|=4.3.1|=4.3.0-r2|=4.3.0-r1|=4.3.0|=4.3.0_rc1|=4.3.0_beta1|=4.2.3-r1|=4.2.3] (rewritten from { =x11-libs/qt-4.4.0_beta1, =x11-libs/qt-4.4.0_rc1, =x11-libs/qt-4.3.4-r1, =x11-libs/qt-4.3.4, =x11-libs/qt-4.3.3, =x11-libs/qt-4.3.2-r1, =x11-libs/qt-4.3.2, =x11-libs/qt-4.3.1-r1, =x11-libs/qt-4.3.1, =x11-libs/qt-4.3.0-r2, =x11-libs/qt-4.3.0-r1, =x11-libs/qt-4.3.0, =x11-libs/qt-4.3.0_rc1, =x11-libs/qt-4.3.0_beta1, =x11-libs/qt-4.2.3-r1, =x11-libs/qt-4.2.3 })':

  ... Downgrade to 'x11-libs/qt-4.3.4-r1:4::gentoo' from 'x11-libs/qt-4.4.0:4::installed' forced

paludis@1211573799: [WARNING dep_list.ignoring_dependencies] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'net-im/skype':

  ... When adding installed package 'net-im/skype-2.0.0.68:0::installed':

  ... Ignoring run dependencies due to exception 'Block: x11-libs/qt-core' (paludis::BlockError)

Query error:

  * In program paludis --pretend --install --dl-downgrade warning world:

  * When performing install action from command line:

  * When executing install task:

  * When building dependency list:

  * When adding PackageDepSpec 'net-print/hpijs':

 * You have 1 unread news items (use 'eselect news' to read)

  * No versions of 'net-print/hpijs' are available.
```

e poi con net-print/hpijs che devo fare? forse perchè è nel file world?

----------

## jordan83

Beh, basta che leggi gli errori, è tutto scritto  :Wink: 

```
paludis --pretend --install --dl-downgrade warning world

Building target list...

Building dependency list...paludis@1211573785: [QA version_spec.too_long] In program paludis --pretend --install--dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding NamedSetDepSpec 'system':

  ... When adding PackageDepSpec 'sys-apps/net-tools':

  ... When fetching versions of 'sys-apps/net-tools' in gentoo:

  ... When loading versions for 'sys-apps/net-tools' in gentoo:

  ... When creating ID for 'sys-apps/net-tools' from '/usr/portage/sys-apps/net-tools/net-tools-1.60_p20071202044231-r1.ebuild':

  ... When extracting version from '/usr/portage/sys-apps/net-tools/net-tools-1.60_p20071202044231-r1.ebuild':

  ... When parsing version spec '1.60_p20071202044231-r1':

  ... Number part '20071202044231' exceeds 8 digit limit permitted by the Package Manager Specification (Paludissupports arbitrary lengths, but other package managers do not)

```

Qui si lamenta del numero di versione, che è troppo lungo e non rispetta gli standard.

Questo è un avviso QA comunque, che puoi ignorare. RIguarda gli sviluppatori più che gli utenti.

```

paludis@1211573786: [WARNING dep_list.downgrade] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'app-emulation/virtualbox-bin':

  ... When adding installed package 'app-emulation/virtualbox-bin-1.5.6:0::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '~app-emulation/virtualbox-modules-1.5.6':

  ... Downgrade to 'app-emulation/virtualbox-modules-1.5.6:0::gentoo' from 'app-emulation/virtualbox-modules-1.5.7:0::installed' forced

```

Qui downgrada app-emulation/virtualbox-modules alla versione 1.5.6 per qualche ragione (prova a guardare la tua configurazione o l'ebuild se sei curioso sul perché).

```

paludis@1211573787: [WARNING dep_list.ignoring_dependencies] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'app-text/kchmviewer':

  ... When adding installed package 'app-text/kchmviewer-3.1_p2:0::installed':

  ... Ignoring run dependencies due to exception 'Error searching for 'app-doc/chmlib': no available versions' (paludis::AllMaskedError)

```

chmlib è stato spostato in dev-libs. Devi reinstallarlo per eliminare questo warning.

```

paludis@1211573787: [QA version_spec.too_long] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'kde-base/kde-meta':

  ... When adding installed package 'kde-base/kde-meta-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=kde-base/kdeadmin-meta-4.0.4:kde-4':

  ... When adding installed package 'kde-base/kdeadmin-meta-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=kde-base/kcron-4.0.4:kde-4':

  ... When adding installed package 'kde-base/kcron-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=kde-base/knotify-4.0.4:kde-4':

  ... When adding installed package 'kde-base/knotify-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=kde-base/phonon-4.0.4:kde-4':

  ... When adding installed package 'kde-base/phonon-4.0.4:kde-4::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec '>=media-libs/xine-lib-1.1.9':

  ... When fetching versions of 'media-libs/xine-lib' in zugaina:

  ... When loading versions for 'media-libs/xine-lib' in zugaina:

  ... When creating ID for 'media-libs/xine-lib' from '/usr/portage/local/layman/zugaina/media-libs/xine-lib/xine-lib-999999999999.ebuild':

  ... When extracting version from '/usr/portage/local/layman/zugaina/media-libs/xine-lib/xine-lib-999999999999.ebuild':

  ... When parsing version spec '999999999999':

  ... Number part '999999999999' exceeds 8 digit limit permitted by the Package Manager Specification (Paludis supports arbitrary lengths, but other package managers do not)

paludis@1211573790: [QA version_spec.too_long] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'media-video/ksubtile':

  ... When adding installed package 'media-video/ksubtile-1.2:0::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec 'media-video/mplayer':

  ... When fetching versions of 'media-video/mplayer' in zugaina:

  ... When loading versions for 'media-video/mplayer' in zugaina:

  ... When creating ID for 'media-video/mplayer' from '/usr/portage/local/layman/zugaina/media-video/mplayer/mplayer-999999999-r7.ebuild':

  ... When extracting version from '/usr/portage/local/layman/zugaina/media-video/mplayer/mplayer-999999999-r7.ebuild':

  ... When parsing version spec '999999999-r7':

  ... Number part '999999999' exceeds 8 digit limit permitted by the Package Manager Specification (Paludis supports arbitrary lengths, but other package managers do not)

```

vedi sopra.

```

paludis@1211573791: [WARNING dep_list.downgrade] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'net-im/skype':

  ... When adding installed package 'net-im/skype-2.0.0.68:0::installed':

  ... When adding run dependencies as post dependencies:

  ... When adding PackageDepSpec 'x11-libs/qt[=4.4.0_beta1|=4.4.0_rc1|=4.3.4-r1|=4.3.4|=4.3.3|=4.3.2-r1|=4.3.2|=4.3.1-r1|=4.3.1|=4.3.0-r2|=4.3.0-r1|=4.3.0|=4.3.0_rc1|=4.3.0_beta1|=4.2.3-r1|=4.2.3] (rewritten from { =x11-libs/qt-4.4.0_beta1, =x11-libs/qt-4.4.0_rc1, =x11-libs/qt-4.3.4-r1, =x11-libs/qt-4.3.4, =x11-libs/qt-4.3.3, =x11-libs/qt-4.3.2-r1, =x11-libs/qt-4.3.2, =x11-libs/qt-4.3.1-r1, =x11-libs/qt-4.3.1, =x11-libs/qt-4.3.0-r2, =x11-libs/qt-4.3.0-r1, =x11-libs/qt-4.3.0, =x11-libs/qt-4.3.0_rc1, =x11-libs/qt-4.3.0_beta1, =x11-libs/qt-4.2.3-r1, =x11-libs/qt-4.2.3 })':

  ... Downgrade to 'x11-libs/qt-4.3.4-r1:4::gentoo' from 'x11-libs/qt-4.4.0:4::installed' forced

```

http://paludis.pioto.org/faq/stricter.html#downgrades

```

paludis@1211573799: [WARNING dep_list.ignoring_dependencies] In program paludis --pretend --install --dl-downgrade warning world:

  ... When performing install action from command line:

  ... When executing install task:

  ... When building dependency list:

  ... When adding PackageDepSpec 'net-im/skype':

  ... When adding installed package 'net-im/skype-2.0.0.68:0::installed':

  ... Ignoring run dependencies due to exception 'Block: x11-libs/qt-core' (paludis::BlockError)

```

probabilmente installare x11-libs/qt-core richiede prima di disinstallare il qt monolitico. Praticamente qt sta bloccando qt-core. Ma siccome puoi usare l'uno o l'altro indifferentemente paludis sputa il warning e procede.

```

Query error:

  * In program paludis --pretend --install --dl-downgrade warning world:

  * When performing install action from command line:

  * When executing install task:

  * When building dependency list:

  * When adding PackageDepSpec 'net-print/hpijs':

```

 *zocram wrote:*   

> 
> 
> e poi con net-print/hpijs che devo fare? forse perchè è nel file world?

 

vedi http://www.gentoo.org/news/en/gwn/20080119-newsletter.xml#doc_chap4

lo hanno rimosso da qualche mese, devi passare a hplip... ^_^

----------

## 102376

ok ti ringrazio ho capito tutto ora. 

ma come mai app-emulation/virtualbox-modules in portage non vuole il downgrade anzi richiede proprio la versione 1.5.7 (forse perchè è smascherata)

ma effettivamente virtualbox-bin è 1.5.6.... e paludis invece vuole fare installare le 1.5.6.

a vederla così è portage che sbaglia

----------

## jordan83

A dire il vero non saprei, dipende tutto da cosa è (o hai) mascherato e/o smascherato e da cosa richiede l'ebuild.

Guardando là di sicuro caprai i motivi per i quali la versione 1.5.6 viene scelta al posto della 1.5.7  :Smile: 

Non c'è nulla di magico in informatica (a parte le schermate blu di Win98 e questo fantastico programma multipiattaforma).  :Smile: 

----------

