Qual é a diferença entre criar arquivos .deb e instalá-los e apenas executar um arquivo .run ?
Qual é a diferença entre criar arquivos .deb e instalá-los e apenas executar um arquivo .run ?
Respostas:
.deb
arquivos são pacotes para o dpkg , o gerenciador de pacotes Debian de baixo nível (que é chamado pelo APT e seus parentes). Um .deb
arquivo é um pacote para o Debian ou para um derivado como o Ubuntu ou o Mint.
Os pacotes Debian contêm os arquivos que pertencem ao pacote, bem como um “arquivo de controle” que descreve as dependências do pacote e outras meta-informações e scripts de instalação que são executados quando o pacote é instalado, atualizado ou desinstalado.
Você pode ver o conteúdo de um .deb
arquivo com dpkg -c
e dpkg -I
. Se você não possui dpkg
, pode ar t foo.deb
listar as partes de um .deb
arquivo e ar x foo.deb control.tar.gz
extrair a control.tar.gz
parte (e da mesma forma para outras partes).
Red Hat (e parentes como CentOS e Fedora), SuSE e outros usam rpm , um formato diferente com características semelhantes. Existem outros em outros sistemas unix.
.run
não é uma extensão padrão. Um .run
arquivo é presumivelmente algo que você pode executar. Pode instalar um programa ou fazer algo completamente diferente.
Em geral, um arquivo .deb é semelhante a um arquivo zip, que contém arquivos juntamente com scripts curtos que podem executar a pós-instalação para adicionar usuários, grupos etc. ao sistema após a instalação.
Um arquivo .run geralmente é um único executável binário ou um script de shell que contém um blob binário que pode ser instalado. Se for a variedade de scripts de shell, muitas vezes conterá um blob binário que geralmente é sinônimo de arquivo zip recursivo ou tar. Em outras palavras, ele conterá estruturas de diretório de arquivos.
Outras vezes, esse tipo de arquivo .run simplesmente conterá arquivos .deb ou .rpm que serão despejados no disco e podem ser instalados individualmente ou o script que os continha, despejá-los no disco e tentar para instalá-los usando o software gerenciador de pacotes do seu sistema.
Um exemplo disso seria se você baixasse o Java JDK do Oracle. É tipicamente um único arquivo executável que quando executado irá copiar os arquivos .deb ou .rpm para o disco, e em seguida, instalá-los usando the package management tools: dpkg
, apt
, yum
ou rpm
.
Aqui está um exemplo de como seria o download / instalação com um desses arquivos .run. A extensão é .bin, mas isso é simplesmente cosmético, a extensão não tem nenhuma relevância além de ajudar os usuários a distinguir entre os diferentes tipos de arquivos.
$ wget http://www.java.net/download/jdk7/archive/b125/binaries/jdk-7-ea-bin-b125-linux-x64-13_jan_2011.bin
$ ./jdk-7-ea-bin-b125-linux-x64-13_jan_2011.bin
Aqui, o arquivo acima irá despejar pacotes para os vários componentes que compõem o JDK, após o qual você pode instalar todos eles ou apenas aqueles que você precisa.
Faça dessa maneira, permitindo que outras coisas sejam feitas além da instalação de um pacote. Por exemplo, a Oracle tem um contrato de licença que eles desejam que você aceite:
10.5 Este Contrato é o contrato completo das partes em relação ao seu objeto. Substitui todas as comunicações, propostas, condições, representações e garantias anteriores ou contemporâneas, ou prevalece sobre quaisquer empresas conflitantes ou adicionais de qualquer citação, pedido, reconhecimento ou outra comunicação entre as partes relacionadas ao seu assunto, incluindo qualquer Licenças de Código, Termos Suplementares ou outras licenças contidas no Software Licenciado. Nenhuma modificação deste Contrato será vinculativa, a menos que por escrito e assinada por um representante autorizado de cada parte.
Você concorda com os termos de licença acima? [sim ou não]
Com este instalador acima, você pode ver que ele contém apenas um blob binário de diretórios de arquivos:
Extracting...
UnZipSFX 5.52 of 28 February 2005, by Info-ZIP (http://www.info-zip.org).
creating: jdk1.7.0/
creating: jdk1.7.0/lib/
inflating: jdk1.7.0/lib/jexec
creating: jdk1.7.0/lib/visualvm/
creating: jdk1.7.0/lib/visualvm/visualvm/
creating: jdk1.7.0/lib/visualvm/visualvm/modules/
inflating: jdk1.7.0/lib/visualvm/visualvm/modules/com-sun-tools-visualvm-attach.jar
inflating: jdk1.7.0/lib/visualvm/visualvm/modules/com-sun-tools-visualvm-host-views.jar
creating: jdk1.7.0/lib/visualvm/visualvm/modules/locale/
...
Nesse caso, esse tipo de instalação visa não chamar o gerenciador de pacotes, mas simplesmente despejar o conteúdo em uma única árvore de diretórios, para que você possa movê-lo para onde quiser.
Em ambientes de produção, geralmente é o caso de você não querer usar o gerenciador de pacotes, mas ter mais controle sobre as implantações. Talvez você tenha vários aplicativos que está implementando e cada um deles exige uma versão diferente do JDK. Usando esse método, é possível que todos coexistam com mais facilidade do que através do gerenciador de pacotes.
$ pwd
/home/saml/jdk1.7.0
[saml@grinchy jdk1.7.0]$ ls -l
total 19308
drwxr-xr-x 2 saml saml 4096 Jan 13 2011 bin
-r--r--r-- 1 saml saml 2487 Jan 13 2011 COPYRIGHT
drwxr-xr-x 5 saml saml 4096 Jan 13 2011 db
drwxr-xr-x 11 saml saml 4096 Jan 13 2011 demo
drwxr-xr-x 3 saml saml 4096 Jan 13 2011 include
drwxr-xr-x 6 saml saml 4096 Sep 29 10:57 jre
drwxr-xr-x 3 saml saml 4096 Sep 29 10:57 lib
-r--r--r-- 1 saml saml 9005 Jan 13 2011 LICENSE
drwxr-xr-x 4 saml saml 4096 Jan 13 2011 man
-r--r--r-- 1 saml saml 25379 Jan 13 2011 README.html
-r--r--r-- 1 saml saml 20320 Jan 13 2011 README_ja.html
-r--r--r-- 1 saml saml 15160 Jan 13 2011 README_zh_CN.html
-r--r--r-- 1 saml saml 5348 Sep 29 10:58 register.html
-r--r--r-- 1 saml saml 5645 Sep 29 10:58 register_ja.html
-r--r--r-- 1 saml saml 4951 Sep 29 10:58 register_zh_CN.html
drwxr-xr-x 8 saml saml 4096 Jan 13 2011 sample
-rw-r--r-- 1 saml saml 19631790 Jan 13 2011 src.zip