| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| *sigh* (Pontos:3, Interessante) |
| | Se queres mesmo seguir uma via dessas, só posso recomendar tar.gz:
Instalas o software todo em /usr/local/opt/prog (que será a PROG_HOME. Pode ser outro sítio melhor, não sei a [G/]LSB toda de cor...)
Instalas o programa propriamente dito em $PROG_HOME/bin/prog.bin e as bibliotecas todas de que necessite em $PROG_HOME/lib/
Colocas em $PROG_HOME/bin/prog um shell script que coloque essas bibliotecas no início do $LD_LIBRARY_PATH
Por fim, cd / ; tar czvf prog-versao.tar.gz $PROG_HOME
|
| |
| |
| | Ja experimentas-te o Makeself pelo que pude ver e bastante bom... e é alias usado pelos drivers da Nvidia entre outros...
|
| |
| | Nunca. Eu não acho essa filosofia adequada. Por vezes é necessária, mas por norma é mau.
Contudo, é um Software Livre que simplifica os passos que sugeri. Pena é ser muito utilizado para a distribuição de software não-livre como os drivers da Nvidia e outros.
|
| |
| | Contudo, é um Software Livre que simplifica os passos que sugeri. Pena é ser muito utilizado para a distribuição de software não-livre como os drivers da Nvidia e outros.
?
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| | "Pena é ser muito utilizado para a distribuição de software não-livre como os drivers da Nvidia e outros."
Queria escrever um comentário, mas nem consigo...
Olha, que se lixe.
Mário Gamito
my web shelter |
| |
| | Eu já desconfiava que ele era o Stallman, mas não quis estragar-lhe o disfarce ;-)
«You cannot steal a gift, which is what code released under the BSD license is.» |
| |
|
| | "Alerta às claques."
Isto agora passou a ser moda, moderam-te para baixo e "ai que há aqui cabala" ?
|
| |
| | Isto agora passou a ser moda, moderam-te para baixo e "ai que há aqui cabala" ?
Não é moda, é constatação de factos:
1. post on-topic
2. responde a uma pergunta feita no artigo com uma possível maneira de fazer o que era perguntado
3. moderação: despropositado
Não sei quanto a ti, mas 1+2=3.
|
| |
| | Mentira 1+2 não é igual a 3, 1+2=10, toda a gente sabe isso.
Eu gostava de ter uma assinatura gira. |
| |
| | desculpa, mas na minha terra 1+1=10...
alias, eu nem sequer sei o que e' essa coisa "2"
:D
Higuita |
| |
| | | foi uma coisa nova que inventaram, mas ainda não sei para que serve. Será para talvez? Já agora porque é que raio o binário é em 0's e 1's e não em 1's e 2's?
Eu gostava de ter uma assinatura gira. |
| |
| | talvez porque, 1=positivo=ligado
e 0=neutro=desligado
tens tambem o exemplo de conducao de corrente eletrica:
1A -> passa corrente, ligado
0A -> nao passa corrente, desligado
claro que neste caso, podia-se dizer 5A ou 8A em vez de 1, mas e' comum tambem normalizar as coisas, para ficar mais simples, logo 5/5 ou 8/8 (intensidade actual/intensidade maxima) e' 1
o ligado e' intensidade maxima, pois senao ja' terias o talvez1, talvez2, talvez3, etc ate' chegar ao sim!! 8)
dizer que 2=desligado/ligado, precisarias de uma imaginacao fertil para inventar algo ;)
Higuita |
| |
|
| | Sem querer prolongar, demais, o offtopic acho que uma moderação para baixo de sobrevalorizado ou assim ao artigo podia ser válida, agora uma moderação de "despopositado", é ela propria despropositada! e no minimo caricata! :-)
Cumprimentos! zp |
| |
| | Alguém que tenha algum tipo de experiência com programas de geração de arquivos de instalação automática de aplicações para Linux independentes da distribuição, poderia partilhar as suas experiências e recomendar algo que realmente funcione bem para este fim?
ja deste uma olhada no loki-setup?
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| |
| | O Loki Setup julgo que seja o programa de instalação mais adequado para newbies disponível.
Só não entendo é porque é só usado para jogos. Embora tenha sido este o propósito do seu desenvolvimente, ele permite a instalação de qualquer tipo de software.
|
| |
| | Ele não é utilizado apenas para jogos. Talvez essas tenham sido apenas as instalações que viste, nisso acredito.
Desde que me lembro, por exemplo, as instalações do Kylix da Borland são feitas com o Loki Setup.
Cheers.
^S^ |
| |
| | Ele não é utilizado apenas para jogos.
Por acaso, desconhecia alguma aplicação, que não um jogo, que o utilizasse.
É bom ver que há gente, que se apercebe das capacidades desta ferramenta.
|
| |
| | se nao quisers fazer o checkout so pra espreitar o codigo, neste ftp estao os binarios, outdated diga-se
ja agora um proj mais ao estilo installshield, q pode ter algum interesse - Installbase,
mas sinceramente como nao especificaste para que fim querias, todas as resposta sao subjectivas quanto a' utilidade e a' dificuldade de implementar determinadas solucoes
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| | neste ftp estao os binarios,
os tgz.. tb sao binarios.. mas enfim :)
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| | O Novo builder da borland (funciona em Windows, Linux e Solaris) traz um tipo de installshield wizard. Ainda nao testei, mas achei curioso que a propria borland nao o usou para o setup do C++BuilderX.
|
| |
| |
| | não experimentei o cbuilder mas jbuilder intala-se tanto em windows como em linux usando o installanywere
|
| |
| | Não sou adepto de closed source software mas já lá vou.
Para as soluções open-source tens sempre o autoconf que é utilizado para compilar configure scripts cuja finalidade é testar portability issues nos target hosts a fim de identificar e corrigir eventuais problemas que possam surgir e que impedem a correcta compilação/execução do código. O autoconf (e outros scripts semelhantes ao configure por ele gerado) funciona perfeitamente no mundo open-source.
Se não queres distribuir a source (não sei porque usas GNU/Linux nesse caso), podes sempre fazer distribuições de software compilado estaticamente tornando-as assim independentes do resto do sistema ou então distribuir as libs necessárias para a execução da aplicação (que é o que acontece em Windows) e ainda tens uma vantagem em relação ao Windows: se copiares shared libraries com uma versão diferente não corres o risco de substituir as já existentes no sistema pois a versão das mesmas costuma fazer parte do seu iname (exemplo.: libtermcap.so.2.0.8) e é contra este iname que as aplicações são linkadas.
"Success reflects luck, not skill!"
-- flock of Balticor |
| |
| |
| | O problema é que é muuuuuito complicado de fazer:
./configure ; make; make install
;)
|
| |
| | O problema é que é muuuuuito complicado de fazer:
./configure ; make; make install
nao, o que e' complicado e' fazer ./configure --help
ou vim Makefile...
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer |
| |
| | O problema é que é muuuuuito complicado de fazer:
./configure ; make; make install
Após isto só posso concluir que nunca tentaste instalar nada não trivial. Já nem vou falar nas dores de cabeça de desinstalar as coisas depois.. mas para isso, suponho que a filosofia m$ de formatar o disco ainda esteja na ordem do dia.
http://www.absolutbsd.org/ |
| |
| | ./configure --prefix=/usr/local/opt/program/ ; make; make install; /usr/local/opt/program/bin/programa
A partir daqui...
yes rula
ou
yuck sucka: rm -fr /usr/local/opt/program ou make uninstall
quem me dera que as minhas dores de cabeça fossem estas...
|
| |
| | Após isto só posso concluir que nunca tentaste instalar nada não trivial.
E eu que nem falei da hipótese que é escrever uma spec de RPM que é o que faço para o software que não tem RPM...
|
| |
| | E que tal o checkinstall? Nao e mais pratico que escrever a spec a la pata? Eu gosto bastante daquilo, especialmente porque me permite configurar tudo como quero e gerar os rpm's logo todos jeitosos... Just my 2 cents..
|
| |
| | Checkinstall é simplesmente excelente!
No entanto, não é um universal installer.... tens que compilar na mesma!
Mas de facto é capaz de ser a melhor coisinha que anda aí... simples, rápido e eficaz... em vez de fazer "make install" faz-se "checkinstall" na directoria onde está a o Makefile...e o milagre acontece! :)
Yours,
McB!
They told me it need Windows 95 or better, so I chose Linux |
| |
| | Uma boa aplicação tem sempre um make uninstall. Alias, a própria GNU recomenda-o!
File: make.info, Node: Standard Targets:
Standard Targets for Users
==========================
(...)
`install'
Compile the program and copy the executables, libraries, and so on
to the file names where they should reside for actual use. If
there is a simple test to verify that a program is properly
installed, this target should run that test.
Do not strip executables when installing them. Devil-may-care
users can use the `install-strip' target to do that.
If possible, write the `install' target rule so that it does not
modify anything in the directory where the program was built,
provided `make all' has just been done. This is convenient for
building the program under one user name and installing it under
another.
The commands should create all the directories in which files are
to be installed, if they don't already exist. This includes the
directories specified as the values of the variables `prefix' and
`exec_prefix', as well as all subdirectories that are needed. One
way to do this is by means of an `installdirs' target as described
below.
Use `-' before any command for installing a man page, so that
`make' will ignore any errors. This is in case there are systems
that don't have the Unix man page documentation system installed.
The way to install Info files is to copy them into `$(infodir)'
with `$(INSTALL_DATA)' (*note Command Variables::), and then run
the `install-info' program if it is present. `install-info' is a
program that edits the Info `dir' file to add or update the menu
entry for the given Info file; it is part of the Texinfo package.
Here is a sample rule to install an Info file:
$(DESTDIR)$(infodir)/foo.info: foo.info
$(POST_INSTALL)
# There may be a newer info file in . than in srcdir.
-if test -f foo.info; then d=.; \
else d=$(srcdir); fi; \
$(INSTALL_DATA) $$d/foo.info $(DESTDIR)$@; \
# Run install-info only if it exists.
# Use `if' instead of just prepending `-' to the
# line so we notice real errors from install-info.
# We use `$(SHELL) -c' because some shells do not
# fail gracefully when there is an unknown command.
if $(SHELL) -c 'install-info --version' \
>/dev/null 2>&1; then \
install-info --dir-file=$(DESTDIR)$(infodir)/dir \
$(DESTDIR)$(infodir)/foo.info; \
else true; fi
When writing the `install' target, you must classify all the
commands into three categories: normal ones, "pre-installation"
commands and "post-installation" commands. *Note Install Command
Categories::.
`uninstall'
Delete all the installed files--the copies that the `install'
target creates.
This rule should not modify the directories where compilation is
done, only the directories where files are installed.
The uninstallation commands are divided into three categories,
just like the installation commands. *Note Install Command
Categories::.
(...)
"Success reflects luck, not skill!"
-- flock of Balticor |
| |
| | recomendo-te o checkinstall para o uninstall...
melhor, instalas com o checkinstall e ele faz-te um pacote da tua distro (bem, pelo menos para rpm ou tgz, .deb nao precisa e nao 8)
depois podes remover como qualquer outro pacote, ou instalar noutras maquinas como qualquer pacote normal
se as instalacoes que falas, dificeis, estas a pensar no gnome, entao calo-me, ja' que teem centenas de dependencias, o resto, geralmente precisas no maximo de mais 2-3 programas que geralmente tambem sao ./configure && make && make install
Higuita |
| |
| | Também uso profusamente o checkinstall. Facilita e muito a (des)instalação de software construido apartir do código-fonte (vulgo source :).
No entanto, tem um pequenito problema, que acho deva ser levado sempre em conta: o método levado a cabo pelo checkinstall baseia-se na detecção, colecção e inclusão de todos os ficheiros criados ou alterados durante a execução do processo 'make install' (sendo este a modalidade por omissão, podendo ser substituido por outro mais específico).
Esses ficheiros farão então parte integrante do RPM (sendo este o meu exemplo) assim gerado.
O tal pseudo-problema ocorre quando queremos eliminar um pacote RPM (rpm -e) gerado desde a compilação de drivers ou módulos para o kernel, sendo este um exemplo em causa.
Normalmente, durante a fase de 'make install' estes pacotes culminam num 'depmod -a' ou algo que o valha. Ou seja, e seguindo o exemplo, todos ficheiros de referência para o hotplugging e para dependências inter-módulos para o kernel vão parar ao pacote RPM.
Ao posteriormente removermos esse pacote (rpm -e), lá se vai uma boa parte da funcionalidade mágica do kernel e muita coisa vai deixar de funcionar.
Para um utilizador não-guru, isto pode ser uma grande dor de cabeça. Fatal mesmo ;)
|
| |
| | | No caso particular do modules.dep isso não devia ser um problema.
Aqui tenho um modules.dep por cada versão do kernel (/lib/modules/`uname -r`/modules.dep). E se utilizares uma localização única para o modules.dep, independente do kernel, então torna-se muito conveninente que este seja re-escrito como parte do processo de boot. Algo que creio que a maior parte das distros faz de qualquer maneira.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | Referia-me também aos /lib/modules/`uname -r`/modules.*map. O modules.dep pode ser reconstruido em quaqluer momento, aliás é isso mesmo que o depmod faz....
|
| |
| | | Se quiserem usar um bom sistema de geração do binário, sugiro-lhes que olhem o scons. Mudei do autoconf/automake para isso e tenho muito menos problemas para manter o sistema de compilação. Mas não é disto que falamos, é de empacotamento. Em princípio, não tenho nenhum problema em complementar as RPM da minha instalação com outras que sigam o LSB. Esta norma (na verdade várias normas) especificam onde devem ficar determinado tipo de ficheiros (em /usr/bin, /var/lib, etc.), define um grupo de bibliotecas dinâmicas presentes num sistema conforme e com que podemos contar quando compilamos uma aplicação. A última versão do VariCAD, por exemplo, está conforme o LSB 1.3, do qual encontramos um pacote em quase todas as distribuições modernas (Mandrake, por exemplo, tem a RPM lsb). Um sistema de empacotamento que não dependesse da distribuição e que fosse ubíquo, por exemplo, o .deb, seria de sobremaneira excelso. Um instalador gráfico seria uma verdadeira desgraça, muito embora se possa vir no futuro a usar um sistema de texto para configurar aplicações aquando da instalação. De qualquer maneira, e falando com alguns empacotadores da Debian, todos tendemos a não gostar disso: um pacote ou deve vir pnroto a utilizar de uma forma fiável, segura e padrão; em alternativa, deve exigir correr do root, depois da instalação e antes do primeiro uso, uma aplicação configuradora, por exemplo, configure-foo. É claro que uma tal aplicação nada tem a ver com a instalação, e isso permite, por exemplo, automatizar as instalações. Francisco Colaço
|
| |
| |
| | A última versão do VariCAD, por exemplo, está conforme o LSB 1.3, do qual encontramos um pacote em quase todas as distribuições modernas (Mandrake, por exemplo, tem a RPM lsb).
A RedHat está a tornar-se a M$ do Linux... Por isso, enquanto a RedHat não aderir ao LSB (Linux Standard Base), não veremos a LSB a ser muito adoptada.
E, já agora, a SuSE também já vem com suporte ao LSB.
|
| |
| | "A RedHat está a tornar-se a M$ do Linux..."
ironic Olha que dizer isso aqui pode valer-te uma ida p'rá fogueira. Herege. /ironic
Mário Gamito
my web shelter |
| |
| Bzzzt! (Pontos:3, Informativo) |
| | A RedHat está a tornar-se a M$ do Linux... Por isso, enquanto a RedHat não aderir ao LSB (Linux Standard Base), não veremos a LSB a ser muito adoptada.
Duas bacoradas de uma vez só, é difícil. Por um lado como pode a Red Hat ser a Microsoft do Linux se lança tudo quanto faz sob GPL? Em segundo lugar a Red Hat há séculos que adere à LSB.
-- Carlos Rodrigues
|
| |
| | | A m$ do GNU/Linux???
Não digas disparates, todo o software da antiga distribuição Red Hat Linux, agora Fedora é Software Livre.
Se te referes às outras distribuições da Red Hat, apesár de terem algum software proprietário, a distribuição não deixa de ser na sua maioria Software Livre.
A Red Hat contribui para vários projectos de Software Livre.
Como vês! A Red Hat também não usa taticas anti-competitivas e e ilegais como a m$ fáz. Não há termo de comparação possivél. Quanto à Red Hat não cumprir o LSB, espero que isto te elucide um pouco mais, porque ou não sabes do que falas, ou alguem enganou-te, porque desde existir o pacote para cumprir LSB, até teres na lista de sistemas certeficados oficialmente: o Red Hat Linux 7.3, o Red Hat Linux 8, o Red Hat Linux 9 e o Red Hat Linux Advanced Server 2.1. Ainda quanto à questão da RH cumprir o LSB, uma pequena pesquisa no site da RH estáva em ordem, é que lá podes ver noticias como esta, isto já para não falar de uma pesquisa no google.
|
| |
