Newsgroup: it.comp.os.linux.iniziare
Titolo: [BlueGriffon) editor HTML installare un pacchetto deb in una .rpm

Ho seguito una guida per installare il pacchetto deb di BlueGriffon:
 
http://bluegriffon.org/#download
 
 
Ubuntu 16.04
(tar.bz2, 64 bits)	
(deb file)
 
l'aspetto peculiare è che ho una distro rpm e che ho potuto installare 
il pacchetto semplicemente de-zippando due volte il file e usando quello 
che è contenuto nella cartella "Data".
 
Ha funzionato, con mia grande sorpresa.
 
Ho semplicemente messo tutti i file nelle cartelle indicate dalle 
sottocartelle di "Data" che erano /usr e /opt, più altre sottocartelle.
 
Da Terminale ho dato $ bluegriffon ed è partito: mi pare funzioni 
perfettamente sulla mia linux rpm.
 
Domanda: è sempre così o è un caso particolare?
 
-- 
Sandro kensan 
www.kensan.it
 & 
www.qiqi.it
 geek site
Saluto gli agenti della NSA - Hello NSA - 
www.nsa.gov
 

 Domanda: è sempre così o è un caso particolare?
 
diciamo più che un caso particolare è un caso semplice o al massimo 
fortuito.
evidentemente è un pacchetto che non ha dipendenze, o se le ha risultano 
soddisfatte per puro caso.


Solo per pignoleggiare.
 
Se le dipendenze sono le librerie del C/C++, non è un caso, le interfacce 
del C/C++ sono molto stabili.
 
Il problema infernale sono le librerie aggiuntive, grafiche, audio, del 
desktop, del kernel, ecc. .
 
E aggiungerei che i pacchetti di installazione fanno anche preparazioni, 
pulizie, migrazioni (a volte fortunatamente ci pensa il programma 
contenuto).

 
 
 
domanda, perchè no hai usato alien? ( a parte flatpack) 
 
Enrico 
 

 Domanda: è sempre così o è un caso particolare?
 
Che un SW di quasi 10 anni fa, non piu`
aggiornato, funzioni ancora?
Oppure che un SW deb Ubuntu 16.04 funzioni
su un'altra distribuzione?
 
Perche` entrambi i casi sembrano peculiari.
 
bye,
 
-- 
 
piergiorgio
 

 contenuto).
 
certo, gestiscono anche un eventuale aggiornamento e la rimozione. 

 Domanda: è sempre così o è un caso particolare?
 
In generale è un caso.
 
Di che distribuzione RPM stiamo parlando?
 
Ad ogni modo come spunto, qui è mostrato come installarlo su fedora.
 
https://tutorialforlinux.com/2021/09/04/step-by-step-bluegriffon-fedora-35-installation-guide/
 

 domanda, perchè no hai usato alien? ( a parte flatpack)
 
Mai usato, al massimo compilato ma per Bluegriffon mi pare sia un po' 
complicato.


 Perche` entrambi i casi sembrano peculiari.
 
La seconda che hai detto:)
 
Anche a me sembra strano e in effetti mi sono meravigliato.


 
https://tutorialforlinux.com/2021/09/04/step-by-step-bluegriffon-fedora-35-installation-guide/
 
 
https://tutorialforlinux.com/2021/09/04/step-by-step-bluegriffon-fedora-35-installation-guide/2/
 
 
manca il link per il download e poi con ublock mancano un sacco di 
parti. Tu vedi il link?



Grazie della risposta. Tra l'altro la mia distro è una beta e la guida 
che ho seguita era della versione precedente, vuol dire che due versioni 
di Mageia sono adatte per avere installato questo programma che non è 
mai stato aggiornato nel frattempo:
 
BlueGriffon®
 
The next-gen Web and EPUB Editor based on the rendering engine of Firefox®
 
Version 3.1 released 2019-oct-14.


 mai stato aggiornato nel frattempo:
 
se un programma ha linkato librerie in modo statico e non ha dipendenze 
dinamiche, è molto facile possa rimanere compatibile con qualsiasi linux a 
qualsiasi release (ovviamente a parità di architettura). 
ovviamente rimane la sua obsolescenza, il motore di rendering firefox è 
quello di 10 anni fa e nel frattempo sarà assai migliorato.

 parti. Tu vedi il link?
 
Sandro, in cima alla pagina c'è il link:
-------------------------------------
2. Downloading BlueGriffon for Fedora
 
Download BlueGriffon for Fedora GNU/Linux
Here Get BlueGriffon tar.bz2 for Fedora
---------------------------------------
 
Quel "Here" è un link che punta a:
 
http://bluegriffon.org/#download
 
 
Ovvero la pagina del progetto in realtà, però ci vuol poco a
trovare il link al tarball:
 
------------
Ubuntu 16.04 ------> questo è un link: ---|
(tar.bz2, 64 bits)                        |
------------------                        v
 
http://bluegriffon.org/freshmeat/3.1/bluegriffon-3.1.Ubuntu18.04-x86_64.tar.bz2
 
 
L'installazione è banale, se poi funzioni o no, bisogna provare.
 
Piuttosto non vedo il codice sorgente lì... ma è scritto che è open.
 
Ah eccolo qui:
 
https://github.com/therealglazou/bluegriffon
 
 
Mmmm, vedo al volo... ma lì non trovi le indicazioni per
il build, c'è un link rotto.
 
Va be', prova il binario da piazzare in /opt.
Se poi qualcosa non funziona penserai a come fare il build
da sorgenti eventualmente.
 
Per lo scopo una strada può essere quella di prendere un'idea
da ad esempio un PKGBUILD di Arch, non è mageia, ma va be'.
Non c'erano anche gli RPMS?
Non so come si faccia ad adattare quello della mageia 7 (dove
c'è bluegriffon) in modo che compili e prepari il pacchetto rpm
per mageia 8.
Prima di Slackware avevo provato Fedora per qualche tempo, ma
non ricordo più granché di come si costruivano i pacchetti.
Per queste operazioni Slackware è molto più banale, o forse
sono io che la conosco meglio. Poi nel caso specifico anche
qui non si trovano slackbuilds di bluegriffon, per cui dovrei
scopiazzare in giro.
Si fa presto a trovare qualche spunto:
 
https://github.com/muflone/pkgbuilds/blob/master/bluegriffon/PKGBUILD
 
 
In ogni caso alla fine non sembra nulla di trascendentale.
E ripeto, non è detto che serva se t'accontenti del binario
precompilato e lo installi come spiegato nella guida.
 
A corollario, questa applicazione non sembra così popolare
considerndo che non si trova un pacchetto già pronto per
la tua distribuzione almeno in versione attuale.
Siamo sicuri che non ci sia qualcosa di meglio per quello
scopo?
Io non ne ho idea, ma la butto lì, perché magari con meno
fatica hai già pronto un tool migliore e più popolare
installabile comodamente col gestore di pacchetti di mageia,
che non ho idea di quale sia... lo saprai tu immagino,
se deriva dal vecchio mandrake sarà un urpmi o similare o
era rpmdrake. L'equivalente su fedora era yum ma ora hanno
cambiato tipo in dfn o dnf o come si chiama.

 qualsiasi release (ovviamente a parità di architettura). 
 
penso anche io che sia cosi'.
ormai anche il piu' piccolo dei sw si porta dietro decine di dipendenze e, per la mia esperienza, manca sempre quella libreria o quel tal pacchetto.
non e' detto poi che, usando una certa "funzione" di quel pacchetto che ha installato, non abbia poi dei problemi perche' mancano delle lib.

 pacchetto.
 
beh io non ricordo mi sia mai accaduta una cosa del genere almeno negli 
ultimi 10 anni, se non forse in qualche tentativo di installare un qualche 
pacchetto azzardato dal repository aur quando ancora sprecavo il mio tempo 
con la arch. di certo mai con i repository ufficiali e/o con il software 
decentemente supportato... 

 quello di 10 anni fa e nel frattempo sarà assai migliorato.
 
Quindi sintetizzando, ci sono possibilità che anche con la prossima 
versione di Mageia non abbia problemi a fare la stessa operazione.


 Here Get BlueGriffon tar.bz2 for Fedora
 
Hai ragione "Here" è cliccabile.


 decentemente supportato...
 
quello si', se usi i repo o sw "official" problemi non ce ne sono.
pero', parlando di sw fuori dai repo, di problemi ne ho avuti parecchi, e infatti se un sw non e' nei repo ufficiali, difficilmente lo installo, mi deve davvero servire e non essercene di simili.

 pero', parlando di sw fuori dai repo, di problemi ne ho avuti parecchi, e infatti se un sw non e' nei repo ufficiali, difficilmente lo installo, mi deve davvero servire e non essercene di simili.
 
Spesso si puo`, facilmente, creare il
pacchetto per il proprio sistema ed
installare quello.
 
Il software di gestione si occupa di
semplificare la vita per quel che
riguarda install / uninstall, varie
ed eventuali (dipendenze).
 
bye,
 
-- 
 
piergiorgio
 


insomma, se il programma non l'hai scritto te conoscere le dipendenze non 
la vedo una cosa proprio facile.


Infatti, se da una parte è facile crearsi il pacchetto, dall'altra
il software può anche non funzionare... basta che manchi una
libreria. Però io parlo per esperienza su Slackware che non considera
le dipendenze a livello di pacchetto (i tgz di slack non contengono info
sulle dipendenze, e il gestore pkgtool quindi intallpkg upgradepkg ecc,
non chiedono nulla in merito).
In pratica installi quel che vuoi, ma se poi qualcosa non funziona a
causa di dipendenze mancanti, be' sono c*i tuoi.
 
C'è da dire che se la pacchettizzazione parte da sorgenti, in fase
di compilazione l'errore salta fuori, anzi già in fase di "configure"
o giù di lì. Ovviamente un occhio ai README e INSTALL va dato.
 
Il problema delle dipendenze non soddisfatte in slack si ha con
pacchetti precompilati presi qua e là. Ma la soluzione lì c'è e
di solito basta leggere un minimo sul sito da cui si scarica quella
roba...
Per il parco software ufficiale di precompilati la prassi di slack
prevede l'installazione completa. In quel modo le dipendenze sono
soddisfatte. La cosa ha un senso considerando che i parco ufficiale
non è esteso come in altre distribuzioni.
Per i pacchetti di terze parti se precompilati serve attenzione,
i "requirements" di un certo software di solito sono specificati.
Per la roba da sorgenti si va di slackbuilds ove possibile, altrimenti
si pacchettizza facilmente ma occorre un minimo di documentazione
su cosa richiede il software sia per girare che in fase di build.
 
 
Comunque per quello che ne so crearsi un pacchetto deb o rpm, che
invece le dipendenze le considerano, è tutta un'altra fazenda, e in
questo senso slackware mi è sempre piaciuta di più. Ma non sono mai
stato un packager debian, e neanche di arch, anche lì le dipendenze
sono richieste a livello di pacchetto se non sbaglio. Insomma quindi
magari parlo a sproposito per poca conoscenza di quei sistemi.
Lo stesso vale per gli rpm... sono pacchetti con più funzionalità
rispetto ad un tgz slackware, proprio perché richiedono che chi li
costruisce si preoccupi di aggiungervi informazioni in più sulle
dipendenze del contenuto.
Poi al solito, la pratica vale più della matamatica, e alla prova dei
fatto può essere che il tutto sia più semplice di quanto si immagini
restando sul piano teorico... che alla fine poi serve a poco.

 di lì. Ovviamente un occhio ai README e INSTALL va dato.
 
beh il make/configure controlla quello che gli serve a compile time, che 
non è necessariamente quello che serve a runtime. quindi andrebbe dato ben 
più di un occhio.
inoltre se uno deve compilare e installare un software per se stesso non 
capisco il valore aggiunto di farsi il pacchetto. altro conto se vuoi 
contribuire a manutenerlo a beneficio di altri.


personalmente e per lavoro installo sul portatile tanto software fuori dal 
repository della distribuzione, spesso anche software che è presente ma 
che non è alla versione che mi serve. dipende sempre da chi e come lo 
supporta. certo non vado in cerca di guai installando sw da sorgenti 
sconosciute o pacchettizzati da chicchessia, direi che in quei casi un 
problema di dipendenze broken sarebbe un male minore.

 la vedo una cosa proprio facile.
 
Allora, dipende da quanto uno
voglia "sporcarsi" le mani.
 
Al primo "make", si vede subito
cosa manca.
 
Tra l'altro, in qualche strano modo,
"rpmbuild" si accorge di alcune
dipendenze e le richiede.
 
bye,
 
-- 
 
piergiorgio
 

 libreria. Però io parlo per esperienza su Slackware che non considera
 
Se manca una libreria, il pacchetto
non viene creato.
 
Parliamo di "C/C++", ovviamente, e compilati
simili (Pascal, Fortran, ADA, ...)
 
Se siamo su Python, allora "requirements.txt"
potrebbe anche aiutare, se l'autore e` benevolo.
 
bye,
 
-- 
 
piergiorgio
 


Certo che è possibile, non esistono solo i sorgenti,
capita anche di pacchettizzare roba distribuita via
binari. In quel caso il pacchetto lo crei senza
compilare nulla, ma poi le dipendenze che richiede
quel software devono essere soddisfatte sul sistema.
 
Non conosco bene gli rpm né i deb, ma per i tgz di
Slackware è così. Pacchettizzi quel che vuoi da binari,
puoi installarlo senza problemi, ma poi se gli eseguibili
inclusi nel pacchetto funzionano o no, non si sà...
 
Se parti da sorgenti, dipende, può esserci anche il
caso che qualcosa anche diversa da librerie che serve in
runtime non sia richiesta in build time. Non escluderei
questa possiblità, ora non mi vengono in mente esempi,
ma non si sa mai.


Perché il pacchetto viene poi gestito facilmente col gestore di pacchetti:
 
- risulta registrato nella lista dei pacchetti installati
- lo puoi facilmente disinstallare
- lo puoi aggiornare con un nuovo pacchetto creato a partire da una
  versione più recente di quel software
- in generale hai il controllo millimetrico e registrato di tutti
  i files che vengono copiati sul sistema con l'installazione
- il punto precedente è importante, ti permette di adattare il
  comportamento in installazione del generico software (previsto
  da chi lo distribuisce, direi attraverso il makefile) allo
  standard della specifica distribuzione.
  Per fare un esempio in slackware si punta DESTDIR su "/usr"
  mentre il default di molti "make install" è "/usr/local".
- Se installi con un "make install" sei probabilmente fregato,
  spesso puoi dare un make uninstall ma mi pare che devi mantenere
  i sorgenti e il configure che hai impostato sul sistema afinché
  funzioni correttamente.
  Proprio per questo c'era un'utility chiamata checkinstall:
 
  se questa è la sequenza classica:
 
  ./configure && make && make install
 
  si usava così, sostituendo l'ultimo comando:
 
  ./configure && make && checkinstall
 
  ne salta fuori un pacchetto deb, rpm o tgz.
  Da lì lo installi con APT, yum, urpmi, o pkgtools, o quel che
  è a seconda dell'ambiente in cui ci si trova.
  Il problema è che checkinstall come tutti gli automatismi non
  fa i miracoli e può saltar fuori un pacchetto che in realtà
  non segue perfettamente lo standard della distribuzione, in certi
  casi funziona tutto lo stesso, in altri no.
 
In pratica col make install, o anche con un'installazione
manuale (perché alla fine si tratta sempre di copiare files qua
e là nel sistema), il sistema non sa nulla di quella installazione,
e con ogni probabilità quei files resteranno sparsi nelle varie
dirs senza possibilità futura di essere gestiti, perché nessuno
si ricorderà più di dove siano stati piazzati.
Non è sicuramente una via da seguire se si vuol tenere il sistema
pulito e sotto controllo.
 
 
Aggiungo che crearsi un pacchetto a mano e basta è una scelta poco
felice. Molto meglio crearsi uno script che pilota la procedura
e crea il pacchetto finale. In questo modo si può testare il
risultato, eventualmente disinstallare, apportare qualche modifica
e ottenere un pacchetto "sano".
Sarà abbastanza facile gestire in futuro quel software:
non si dovrà rifare tutto, ma solo apportare qualche piccola modifica
allo script di cui sopra, nella stragrande parte dei casi basta
modificare la variabile VERSION o equivalente e impostarla alla
nuova versione del software.
Su slackware si usano gli SlackBuilds che sono semplici script
bash... in pratica scrivi in un file di testo i passaggi che faresti
a mano al terminale.. in più impiegando qualche variabile e qualche
eventuale controllo, ma niente di ché.
Su Arch ci sono i PKGBUILD che sono un pelo più sofisticati ma
anche più puliti se vogliamo.
Su debian non ho idea di qualcosa di equivalente, ma a livello
avanzato la conosco poco, idem per le varie più o meno derivate
red hat basate su rpm.
Anche su BSD ci sono i ports, praticamente dei makefile con varie
funzionalità aggiuntive, da cui prendere spunto immagino per crearsi
degli analoghi fatti in casa per gestire software esotici.
 
Per un'idea di SlackBuilds il punto di riferimento è SBo:
 
slackbuilds.org
 
 
Per i PKGBUILD di Arch si può vedere il repo Aur.
 
 
Infine il polso della situazione.
Tutto questo discorso ha un'importanza relativa, perché crearsi il
pacchetto non è un'esigenza quotidiana. Casi ridotti nel numero e
nel conseguente tempo che richiedono per essere gestiti dall'utente.
 
Questo forse è il punto più importante da mettere in evidenza:
se di un certo programma ci sono molte alternative più popolari
già disponibili pacchettizzate, forse non è il caso di andarsi
ad arrampicare su applicazioni meno diffuse od obsolete... in
quanto tali, è facile che non siano migliori delle prime tanto
più perché si portano dietro la necessità di queste operazioni
aggiuntive per installarle e gestirle.

 ma non si sa mai.
 
Di solito in build-time vi sono piu`
dipendenze, che in run-time.
 
Ma che io sappia, il build di solito
si preoccupa di trovare le dipendenze
che serviranno in run-time.
D'altro canto dipende dal build system
che viene fornito da chi fa il SW.
Make+configure, cmake, bazel, requirements.txt
e quanto altro si possono inventare.
 
YMMV, ma non mi sembra un problema cosi`
da fantascienza.
 
D'altro canto, nel caso qui esposto,
cioe` "bluegriffon", io farei il
pacchetto, il che risolve un sacco
di problemi.
 
Il solo rischio (che qualcosa non
funzioni) di installare un pacchetto
Ubuntu 16.04 (quasi 10 anni) su un
sistema moderno andrebbe considerato
come costo piu` alto che rifarsi tutto
in casa.
 
bye,
 
-- 
 
piergiorgio
 

 in casa.
 
Facendo il pacchetto puoi provare a partire dal tarball dei binari.
Se poi qualcosa non funziona disinstalli il pacchetto. E riprovi
partendo dai sorgenti, che richiede un po' più di documentazione...
non tanta direi in ogni caso.

 pacchetti:
 
continuo a non capire il valore aggiunto, limite mio. praticamente si 
tratta di fare il lavoro del mantainer del pacchetto, per carità se ho 50 
macchine su cui installarlo può anche avere senso ma se è solo per la 
stessa macchina su cui faccio la build mi pare francamente un film con la 
trama esagerata... 


Se lo installi a mano:
 
- e un domani lo vuoi rimuovere
- e un domani lo vuoi aggiornare
 
come procederesti?
 
Forse sono io a non aver afferrato il dubbio che hai espresso.

 non tanta direi in ogni caso.
 
Fai prima dai sorgenti, fidati.
 
Di solito io faccio cosi`:
 
1) cerco una qualche anima pia che
abbia gia` un .spec file (rpm) per
quel SW
1bis) in alternativa, prendo uno
.spec file di qualcosa di simile.
2) modifico tale .spec file facendo
un po' di tuning del caso
3) rpmbuild -ba file.spec
 
Poi si vede cosa succede, inizia a
lamentarsi che manca questo o quello,
oppure che qualche versione non va
bene, etc.
 
Dopo un paio di iterazioni di solito
funziona e poi funziona per sempre
(o quasi).
 
bye,
 
-- 
 
piergiorgio
 

 .spec file di qualcosa di simile.
 
Sì, ad esempio di slackbuilds su SBo si trovano
anche dei modelli da riempire... ci sta.

 dei binari.
 
Come scrivevo, preferirei sempre
compilare, se possibile.
 
bye,
 
-- 
 
piergiorgio
 

 compilare, se possibile.
 
In generale anche io. Poi il giusto mezzo va riconosciuto,
se hai da installare dei malloppi enormi e magari li vuoi
aggiornare spesso, la cosa diventa fattibile solo se hai
un hardware davvero potente o sei disposto a lasciare il
PC per troppo tempo in stato di catalessi in balia di make,
cmake ecc... Direi che la cosa giusta sia regolarsi a seconda
delle proprie esigenze. Snon frasi ovvie ma alla fine nella
pratica hanno il loro perché dopo tutto.

 come procederesti?
 
"storicamente" compilando dai sorgenti chiamo configure con l'opzione --
prefix ed uso stow per creare link simbolici nei percorsi standard. per 
aggiornare compilo con un prefix diverso e sempre con stow aggiorno i 
symlink. per rimuovere cancello semplicemente la directory. 
cosa simile anche quando installo i binari da un archivio compresso, 
scompatto in una directory e poi con i link simbolici (usando ad es. 
alternatives) giostro le versioni.
 
 

 dipendenze.
]zac[
 
Non uso o compilo spesso da file tar (uso sistemi senza risoluzione delle 
dipendenze solo come ultime risorse), ma alcuni avevano (specialmente in 
tempi recenti) una marea di dipendenze.
 
Probabilmente perché ormai anche i specifici sistemi che a volte sono 
usati (php, python, java, ecc) hanno dei loro comandi per installare il 
loro pacchetti automaticamente e con gestione delle dipendenze.
 
E forse perché almeno hanno la vecchia gestione in stile autotools o 
cmake, che fornisce chiari indizi su cosa installare con il normale 
gestore dei pacchetti.

 ben più di un occhio.
]zac[
 
Più non che si, autotools e cmake forniscono una serie di comandi per si 
compilare (non è obbligatorio), ma anche verificare se è presente una cosa 
e in che versione e dari chiari indizi in caso di mancanza, e per 
installare e disinstallare.
 
Personalmente, su una cosa di anni fa e ormai dismessa, l'ho usato per 
gestire la traduzione in lingua di uno script di backup, la sua 
installazione, e la verifica di dipendenze,


Ci sta tutto, io dico sempre, ad ognuno il suo. Ma non è che il tuo
metodo sia più semplice che crearsi un pacchetto più o meno aderente
allo standard della propria distribuzione.
In Slackware, ma in generale per pacchettizzare un software da sorgenti un
po' ovunque, fai la stessa cosa: controlli con configure
 
  ./configure --prefix=/usr
 
e a seconda del makefile, cui va sempre dato un occhio:
 
  make DESTDIR=/tmp/pacchetto install
 
In quel modo hai in "/tmp/pacchetto" il contenuto del futuro pacchetto.
Poi per crearlo effettivamente, in slackware fai:
 
  cd /tmp/pacchetto
  mkdir install
  touch install/slack-desc
 
lo slack-desc è un semplice file di testo informativo, di 12 righe fatto
così (va be' in realtà possono starci righe commentate con # e righe vuote
precedenti):
 
=== inizio slack-desc
       |-----handy-ruler------------------------------------------------------|
appname: appname (Short description of the application)
appname:      <this line is generally left blank>
appname: Description of application  -  this description should be fairly
appname: in-depth; in other words, make it clear what the package does (and 
appname: maybe include relevant links and/or instructions if there's room),
appname: but don't get too verbose.  
appname: This file can have a maximum of eleven (11) lines of text preceded by
appname: the "appname: " designation.  
appname:
appname: It's a good idea to include a link to the application's homepage too.
appname:
=== fine slack-desc
 
Ovviamente se parliamo di una roba homemade per sè si può mettere giusto il
nome e le altre righe restano vuote a parte il campo "appname:".
Al limite si può fare senza slack-desc.
Bon, a quel punto:
 
  makepkg -l y -c n ../appname-version-arch-tag.tgz
 
"appname" deve essere uguale ad "appname:" che appare nello slack-desc.
 
In questo modo avremoo il nostro pacchetto in /tmp.
 
per installarlo:
 
  installpkg /tmp/appname-version-arch-tag.tgz
 
per rimuoverlo:
 
  removepkg appname
 
per aggiornarlo con un pacchetto più recente "new_version":
 
  upgradepkg /tmp/appname-new_version-arch-tag.tgz
 
 
Riferimenti:
 
https://www.slackwiki.com/Building_A_Package
 
---------------------------
The "i don't have time" way
---------------------------
Fortunately, Slackware are pretty flexible too.
If you don't mind much about what is the source (beware!)
that you're compiling you can burn some stages and do
something like this:
 
  ./configure --prefix=/usr
  make install DESTDIR=$(pwd)/PACKAGE
  cd $(pwd)/PACKAGE
  makepkg -l y -c n ../app-version-arch-tag.tgz
  installpkg ../app-version-arch-tag.tgz
 
Of course, you will have a package without description,
(probably) uncompressed man pages and unstripped binaries.
----------------------------------------------------------
 
Tanto per dare un link...
Cioè alla fine in teoria ci vuol poco a farsi il pacchetto.
Come già detto io preferisco piazzare quei comandi in uno
script bash (slackbuild), che così resta la ricetta e non
devo rifarlo a mano in futuro. In più posso fare pulizia
e buttar via anche il pacchetto tgz che resterebbe in /tmp.
 
Come si vede in Slackware il pacchetto è poco più che un
tarball, non contiene riferimenti a vincoli sull'installazione
legati a questa o quella dipendenza, con pro e contro annessi;
il punto è che questa mancanza rende la pacchettizzazione
da zero molto più semplice che in altre distribuzioni.
 
Però anche nel link sopra è specificato "beware!".
Morale: quando si installa da sorgenti, specie se è un
software un po' più complesso, serve sempre una fase di
documentazione e testing. Non ci sono pasti gratis, nè
automatismi che prevengano incasinamenti vari.
Per questo torno a dire, meglio usare pacchetti o script
di build già collaudati. In altre parole puntare su
applicazioni popolari laddove possibile.
Questo se si vuole far presto e usare il programma...
Se invece si vuole imparare e si hanno finalità didattiche
o si vuole pacchettizzare per contribuire alla community
allora è un altro discorso e documentarsi diventa quasi il
fine più che una scocciatura.

 un po' ovunque, fai la stessa cosa: 
 
si ma è proprio il passaggio di pacchettizzare che trovo superfluo. 


Ho provato a descrivere perché non sia così superfluo. Dopo tutto
mi pare superfluo tanto quanto fare link simbolici. Ma sono il primo
a tener strette le abitudini, per cui ad ognouno il suo.
Ho riportato la speedyway per creare un pacchetto al volo perchè alla
fine in tanti casi tempo non se ne perde poi troppo. Direi lo stesso
di dare make install e quello che viene dopo.
Poi ripeto, a ognuno il suo. Ciao

 si ma è proprio il passaggio di pacchettizzare che trovo superfluo.
 
Sto usando la slackware dal lontano 1996 e ancora sulle 4 macchine che 
ho sulla mia rete sto usandola, anche se con diverse release.
 
Dopo le prime esperienze di installazione 'diretta' ho imparato a mie 
spese dei casini che si fanno se poi non puoi tornare indietro. E non è 
che a quei tempi ci fossero sorgenti col 'make uninstall'.
 
Anche quando ricompilo il kernel rifaccio un pacchetto .tgz (alla moda 
slackware).
 
Anche per programmi che ho portato sulla debian dell'università ho 
creato dei pacchetti .tar.gz (installati su /usr/local) per poterli poi 
rimuovere più facilmente.
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
https://giovanni.homelinux.net/
 >

 rimuovere più facilmente.
 
ma infatti sono stato il primo a dire che per distribuire su altri 
computer è utile fare il pacchetto. in quel caso avrei fatto un deb per 
installarlo con il suo package manager.