View previous topic :: View next topic |
Author |
Message |
yayo Tux's lil' helper
![Tux's lil' helper Tux's lil' helper](/images/ranks/rank_rect_1.gif)
![](images/avatars/1783025581645162f51e6fa.jpg)
Joined: 19 May 2014 Posts: 93
|
Posted: Sun May 14, 2023 12:46 am Post subject: salvare un pacchetto programmato per la rimozione |
|
|
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 |
|
![](templates/gentoo/images/spacer.gif) |
fedeliallalinea Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
![](images/avatars/161653968057192eb39329f.jpg)
Joined: 08 Mar 2003 Posts: 31171 Location: here
|
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
luna80 Veteran
![Veteran Veteran](/images/ranks/rank_rect_5_vet.gif)
![](images/avatars/129716452142b78b3e486e9.gif)
Joined: 01 Feb 2004 Posts: 1555 Location: switzerland
|
Posted: Sun May 14, 2023 10:13 am Post subject: |
|
|
potresti metterlo in un repos locale _________________ *** !f j00 c4n r34D tH15 tH3N j00 n33D t0 l0g Off *** |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
yayo Tux's lil' helper
![Tux's lil' helper Tux's lil' helper](/images/ranks/rank_rect_1.gif)
![](images/avatars/1783025581645162f51e6fa.jpg)
Joined: 19 May 2014 Posts: 93
|
Posted: Tue May 16, 2023 1:58 pm Post subject: |
|
|
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 |
|
![](templates/gentoo/images/spacer.gif) |
fedeliallalinea Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
![](images/avatars/161653968057192eb39329f.jpg)
Joined: 08 Mar 2003 Posts: 31171 Location: here
|
Posted: Wed May 17, 2023 5:24 am Post subject: |
|
|
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 |
|
![](templates/gentoo/images/spacer.gif) |
yayo Tux's lil' helper
![Tux's lil' helper Tux's lil' helper](/images/ranks/rank_rect_1.gif)
![](images/avatars/1783025581645162f51e6fa.jpg)
Joined: 19 May 2014 Posts: 93
|
Posted: Thu May 18, 2023 12:40 am Post subject: |
|
|
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 |
|
![](templates/gentoo/images/spacer.gif) |
yayo Tux's lil' helper
![Tux's lil' helper Tux's lil' helper](/images/ranks/rank_rect_1.gif)
![](images/avatars/1783025581645162f51e6fa.jpg)
Joined: 19 May 2014 Posts: 93
|
Posted: Thu Jun 22, 2023 8:11 pm Post subject: |
|
|
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 |
|
![](templates/gentoo/images/spacer.gif) |
|
|
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
|
|