Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
salvare un pacchetto programmato per la rimozione
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian)
View previous topic :: View next topic  
Author Message
yayo
Tux's lil' helper
Tux's lil' helper


Joined: 19 May 2014
Posts: 100

PostPosted: Sun May 14, 2023 12:46 am    Post subject: salvare un pacchetto programmato per la rimozione Reply with quote

ciaoo! : )

Ho visto che il pacchetto pcsxr è in fase di rimozione in quanto difettoso e non più mantenuto da tempo.
Concordo che non sia il massimo, ma mi pare sia l'unico emulatore psx nei software di gentoo.
Al momento lo uso pochissimo, ma mi dispiacerebbe non averlo più.

Visto che l'ho installato ed è ancora funzionante, è possibile reimpacchettarlo in qualche modo?
Tipo ricompilarlo come file statico o qualcosa del genere?
Back to top
View user's profile Send private message
fedeliallalinea
Administrator
Administrator


Joined: 08 Mar 2003
Posts: 31343
Location: here

PostPosted: Sun May 14, 2023 5:56 am    Post subject: Reply with quote

Hai provato games-emulation/duckstation dall;overlay guru.
_________________
Questions are guaranteed in life; Answers aren't.
Back to top
View user's profile Send private message
luna80
Veteran
Veteran


Joined: 01 Feb 2004
Posts: 1560
Location: switzerland

PostPosted: Sun May 14, 2023 10:13 am    Post subject: Reply with quote

potresti metterlo in un repos locale
_________________
*** !f j00 c4n r34D tH15 tH3N j00 n33D t0 l0g Off ***
Back to top
View user's profile Send private message
yayo
Tux's lil' helper
Tux's lil' helper


Joined: 19 May 2014
Posts: 100

PostPosted: Tue May 16, 2023 1:58 pm    Post subject: Reply with quote

ok, rieccomi.
Scusate, sto facendo dei backup 'sti giorni, ma sto litigando con spacefm che ha iniziato ad andare in crash per segmentation fault ad ogni smontaggio di dispositivi/partizioni. Lo faceva anche prima trascinando i file nell'albero delle cartelle, ma bastava stare attenti a non farlo. Adesso è un po' più complicato.
Nessuno dei due casi di crash è menzionato nella lista dei bug, e sembra che di suo non abbia nemmeno un'opzione per il debug...
grr! è_é

vabé, tornando all'emulatore.

Partendo dall'ultimo suggerimento, fare un repository locale:
è una cosa che avevo pianificato di imparare/fare da un po' di tempo, per qualsiasi caso in cui possa servirmi, ma non ho ancora avuto modo di approfondire.
Però nel caso specifico ho dei dubbi. Mi par di capire che mettere il pacchetto in un repository locale vuol dire che posso compilarlo e installarlo quando mi pare dal mio pc. Ma come funziona poi con le dipendenze?
Con equery g pcsxr rilevo un albero di 24 dipendenze. Cosa succede se fra qualche mese uno di questi pacchetti viene sostituito o aggiornato e pcsxr non trova quel che cerca? Si blocca?
Queste dipendenze sono necessarie per la compilazione o per il funzionamento attivo (runtime)? O tutte e due?
Code:
* dependency graph for games-emulation/pcsxr-1.9.94_p20190306-r1
 `--  games-emulation/pcsxr-1.9.94_p20190306-r1  M[package.mask]
   `--  dev-libs/glib-2.76.2  (dev-libs/glib) amd64
   `--  media-libs/libsdl2-2.26.2  (media-libs/libsdl2) amd64  [joystick]
   `--  sys-libs/zlib-1.2.13-r1  (sys-libs/zlib) amd64
   `--  x11-libs/gtk+-3.24.37  (x11-libs/gtk+) amd64
   `--  x11-libs/libX11-1.8.4-r1  (x11-libs/libX11) amd64
   `--  x11-libs/libXext-1.3.5  (x11-libs/libXext) amd64
   `--  x11-libs/libXtst-1.2.4  (x11-libs/libXtst) amd64
   `--  x11-libs/libXv-1.0.12  (x11-libs/libXv) amd64
   `--  x11-libs/libXxf86vm-1.1.5  (x11-libs/libXxf86vm) amd64
   `--  virtual/libintl-0-r2  (virtual/libintl) amd64
   `--  virtual/opengl-7.0-r2  (virtual/opengl) amd64
   `--  app-arch/libarchive-3.6.2-r1  (app-arch/libarchive) amd64
   `--  media-libs/alsa-lib-1.2.8-r1  (media-libs/alsa-lib) amd64
   `--  dev-libs/libcdio-2.1.0-r1  (dev-libs/libcdio) amd64
   `--  media-video/ffmpeg-4.4.3  (>=media-video/ffmpeg-3) amd64
   `--  media-libs/openal-1.23.1  (media-libs/openal) amd64
   `--  media-sound/pulseaudio-16.1  (media-sound/pulseaudio) amd64
   `--  x11-base/xorg-proto-2022.2  (x11-base/xorg-proto) amd64
   `--  dev-util/desktop-file-utils-0.26-r2  (dev-util/desktop-file-utils) amd64
   `--  x11-misc/shared-mime-info-2.2  (x11-misc/shared-mime-info) amd64
   `--  app-arch/unzip-6.0_p27-r1  (app-arch/unzip) amd64
   `--  sys-devel/gettext-0.21.1  (sys-devel/gettext) amd64
   `--  dev-util/ninja-1.11.1-r2  (>=dev-util/ninja-1.8.2) amd64
   `--  dev-util/cmake-3.26.3  (>=dev-util/cmake-3.20.5) amd64
[ games-emulation/pcsxr-1.9.94_p20190306-r1 stats: packages (25), max depth (1) ]

È per questo che parlavo di compilarlo statico. Se il binario è autosufficiente (anche se magari è grosso come un elefante) poi per qualche anno lo uso così, come eseguibile (a patto che funzioni mettendo tutti i suoi file dentro la sua cartella).
Il fatto è che non c'è l'opzione, la use flag per compilarlo statico non c'è proprio... xD


Mentre per l'alternativa da overlay:
è una opzione molto interessante. Anche in generale intendo: attingendo agli overlay il ventaglio di applicazioni si allarga molto di più.
Ma non ho mai usato archivi di app diversi da quello standard, diciamo per evitare rischi di instabilità e per non complicarmi troppo la vita.
Quindi... non so come si fa. : P

Praticamente vuol dire avere 2 (o magari più) alberi di pacchetti da aggiornare col sync ogni volta invece di uno? Non è complicato? : ?
Oppure si prende e si aggiorna solo la app che serve?
I pacchetti degli overlay dipendono sempre dai pacchetti dell'albero standard?
Back to top
View user's profile Send private message
fedeliallalinea
Administrator
Administrator


Joined: 08 Mar 2003
Posts: 31343
Location: here

PostPosted: Wed May 17, 2023 5:24 am    Post subject: Reply with quote

yayo wrote:
Però nel caso specifico ho dei dubbi. Mi par di capire che mettere il pacchetto in un repository locale vuol dire che posso compilarlo e installarlo quando mi pare dal mio pc. Ma come funziona poi con le dipendenze?

Devi gestire anche queste se in futuro una di esse viene tolta o una versione non è più compatibile con il programma.

yayo wrote:
Queste dipendenze sono necessarie per la compilazione o per il funzionamento attivo (runtime)? O tutte e due?

Puoi vedere nell'ebuild quale siano le dipendenze runtime (RDEPEND) o per la fase di compilazione (BDEPEND).
Anche semplicemente usare ldd sull'eseguibile.

Effettivamente con il tempo riuscire a fare compilare questo pacchetto sarà difficile con le nuove versioni delle dipendenze.

A questo punto forse ti conviene creare una AppImage (non l'ho mai fatto) piuttosto che compilare tutto staticamente
_________________
Questions are guaranteed in life; Answers aren't.
Back to top
View user's profile Send private message
yayo
Tux's lil' helper
Tux's lil' helper


Joined: 19 May 2014
Posts: 100

PostPosted: Thu May 18, 2023 12:40 am    Post subject: Reply with quote

Ok, mi confermi che più o meno è come immaginavo.
Credo che il repository locale sia più adatto per pacchetti con dipendenze minime o assenti.

Molto interessante invece quella cosa dell'appimage. Non la conoscevo.
Ma ho paura che sia più complicato di quel che sembra.

Ho dato un'occhiata alla documentazione.
Sicuramente facendolo tutti i giorni viene facile, ma non sapendone niente devo dire che nonostante la documentazione sono piuttosto confuso... : P

Se ho capito bene per fare, per esempio, un impacchettamento manuale (come spiegato qui: https://docs.appimage.org/packaging-guide/manual.html#creating-an-appdir-manually) dovrei cominciare creando una lista di file da impacchettare, quindi i file del programma ("eselect f pcsxr") più le librerie di cui ha bisogno ("ldd /usr/bin/pcsxr"). E fin quà è facile.
Ma i binari devono essere "spostabili", cioè non avere codificati internamente percorsi fissi.
Quindi verificando (con "strings /usr/bin/pcsxr | grep /usr"), si ottiene una lista di percorsi da cambiare o a livello sorgente (poi da ricompilare), o direttamente nel binario, sempre che la app non faccia un chdir(), perché allora non funziona.
Sarebbe fattibile anche questo sul solo binario pcsxr, ma il procedimento sembra vada ripetuto anche per tutte le librerie usate, che nel caso, come da "ldd" di cui sopra, sono 85 file.
A livello di sorgente mi pare un macello, a livello di binario forse... facendo una copia di tutti i file in una cartella e poi patchandoli tutti... ??

Continuo a leggere per chiarire tutte le opzioni, ma ho la sensazione che sia un cosa più adatta agli sviluppatori che non all'utente finale...

Mi domando se avendo un precompilato x win mi funzionerebbe sul wine senza tutti sti problemi... : ?
Back to top
View user's profile Send private message
yayo
Tux's lil' helper
Tux's lil' helper


Joined: 19 May 2014
Posts: 100

PostPosted: Thu Jun 22, 2023 8:11 pm    Post subject: Reply with quote

Aggiornamento.
Ho provato a recuperare in qualche modo il binario visto che è già compilato, ma ovviamente se non è statico non funziona e basta.
Quindi, secondo indicazione di questo thread https://forums.gentoo.org/viewtopic-t-1163478.html , ho provveduto a installare mednaffe+mednafen, in quanto mi par di capire sia l'unica alternativa disponibile sul repository base.

Non ho ancora avuto modo di testarlo estensivamente, ma ho lanciato un gioco e sembra funzionare bene, quindi dovrebbe essere ok, solo da impostare un po'.
(Tipo capire come recuperare i file delle memory-card: usa lo stesso formato? e in che cartella devo mettere i file? cose così...)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Forum italiano (Italian) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum