Desenvolvedores Debian se comunicam com outros criadores de distribuições do Linux para manter compatibilidade binária entre as distribuições. A maior parte dos produtos comerciais para Linux rodam tão bem na Debian quanto no sistema sobre o qual foram construídos.
A Debian GNU/Linux adere à Estrutura de Sistema de Arquivos do Linux (Linux File System Structure). Apesar disso, existe espaço para interpretações em algumas das regras dentro desse padrão, então podem existir diferenças entre um sistema Debian e outros sistemas Linux. A mais nova versão desse padrão FSSTND é chamada de FHS e planejamos mudar para ela em pouco tempo.
Para a maior parte dos aplicativos, o código fonte do Linux é compatível com outros sistemas Unix. Ele tem suporte a praticamente tudo o que está disponível em sistemas Unix System V e derivados livres e comerciais do BSD. No mundo Unix, porém, essa afirmação praticamente não tem valor, pois não há como prová-la. Na área de desenvolvimento de software é necessário haver compatibilidade completa ao invés de compatibilidade na "maioria" dos casos. Por causa disso, anos atrás surgiu a necessidade de padrões, e hoje em dia o POSIX.1 (IEEE Standard 1003.1-1990) é um dos principais padrões para compatibilidade a nível de código fonte entre sistemas operacionais estilo Unix.
O Linux pretende aderir ao POSIX.1, mas os padrões POSIX custam muito dinheiro e o certificado POSIX.1 (e FIPS 151-2) é realmente caro; isso dificulta o trabalho de conformidade completa com o POSIX por parte dos desenvolvedores do Linux. Os custos da certificação fazem com que seja improvável que a Debian receba um certificado de conformidade oficial mesmo que ela passe completamente pelo conjunto de validação. (O conjunto de validação agora está disponível livremente, portanto espera-se que mais pessoas trabalhem em questões acerca do POSIX.1.)
A Unifix GmbH (Braunschweig, Alemanha) desenvolveu um sistema Linux que recebeu certificação de conformidade ao FIPS 151-2 (um superconjunto do POSIX.1). Essa tecnologia esteve disponível na distribuição da própria Unifix, chamada Unifix Linux 2.0, e no Linux-FT da Lasermoon.
Diferentes distribuições do Linux usam diferentes formatos de pacotes e programas de gerenciamento de pacotes.
Existe um programa para descompactar um pacote Debian num computador com outra distribuição do Linux, e normalmente irá funcionar no sentido de que os arquivos vão ser descompactados. A recíproca provavelmente também é verdadeira, ou seja, um programa para descompactar um pacote do RedHat ou Slackware num computador baseado no Debian Linux provavelmente conseguirá descompactar o pacote e colocar a maior parte dos arquivos nos lugares corretos. Isso é conseqüência da existência do (e grande conformidade com o) Padrão de Hierarquia para o Sistema de Arquivos do Linux (Linux File System Standard).
A maior parte dos gerenciadores de pacotes escrevem arquivos de administração quando são usados para descompactar um arquivo. Esses arquivos de administração geralmente não são padronizados. Portanto, o efeito de descompactar um pacote Debian em um computador "estranho"
irá gerar efeitos imprevisíveis (certamente improdutivos) no gerenciador de pacotes daquele sistema. Do mesmo modo, utilitários de outras distribuições podem conseguir descompactar seus arquivos em sistemas Debian, mas provavelmente farão o sistema de gerenciamento de pacotes da Debian falhar quando chegar a hora de atualizar ou remover alguns pacotes, ou simplesmente listar exatamente quais pacotes estão presentes em um sistema.
O Padrão de Hierarquia para o Sistema de Arquivos
do Linux (e portanto Debian GNU/Linux) exige que subdiretórios sob
/usr/local/ fiquem completamente sob a responsabilidade do usuário.
Portanto, os usuários podem descompactar pacotes "estranhos" dentro desse
diretório, e gerenciar sua própria configuração, atualização e remoção
individualmente.
Você ainda tem um programa assim?
Para executar um programa cujo binário esteja em formato a.out
(isto é, QMAGIC ou ZMAGIC),
a.out, seja
diretamente (CONFIG_BINFMT_AOUT=y) ou como módulo (CONFIG_BINFMT_AOUT=m).
(O pacote kernel-image da Debian possui o módulo binfmt_aout.)
Se sua kernel suporta binários a.out por módulo, garanta que o
módulo binfmt_aout esteja carregado. Você pode fazer isso durante
a inicialização incluindo a linha binfmt_aout no arquivo
/etc/modules. Você pode fazer isso a partir da linha de comando
executando o comando insmod NOMEDIR/binfmt_aout.o, onde
NOMEDIR é o nome do diretório onde os módulos que foram construídos
para a versão da kernel sendo rodada estão armazenados. Em um sistema com
a versão 2.0.36 da kernel, NOMEDIR provavelmente é
/lib/modules/2.0.36/fs/.
libc4.
Até a Debian 2.0 ser lançada, é provável que o pacote libc4 já tenha
sido removido da distribuição. Se esse for o caso, você pode querer dar uma
olhada em um CD-ROM antigo da Debian (a Debian 1.3.1 ainda tinha esse pacote).
a.out,
então instale o pacote xcompat.
Se você possui um aplicativo comercial em a.out, este seria um bom
momento para pedir que enviem uma atualização em ELF.
Sim. Basta instalar os pacotes necessários da seção oldlibs,
que estão incluídos na Debian 2.0 para manter a compatibilidade com
aplicativos antigos.
Sim. Na Debian, seu sistema pode ser completamente atualizado para libc6
(incluindo os pacotes de desenvolvimento), e ainda assim é possível
desenvolver programas para libc5. Basta instalar os pacotes -altdev
necessários. O conjunto mínimo de pacotes de que você vai precisar é:
altgcc na seção devel e libc5-altdev na seção
oldlibs.
Então você terá que colocar as ferramentas libc5 antes das
ferramentas normais em seu path. Ou seja, execute o comando export
PATH=/usr/i486-linuxlibc1/bin:$PATH (Isso não é essencial, apenas
vantajoso.) Se você irá fazer isso apenas uma vez, pode executar:
PATH=/usr/i486-linuxlibc1/bin:$PATH make [target].
Arquivos sob o diretório /usr/local/ não estão sob controle do
sistema de gerenciamentos de pacotes Debian. Assim sendo, é boa prática
colocar o código fonte de seu programa em /usr/local/src/. Por exemplo,
você pode extrair os arquivos de um pacote chamado "foo.tar"
dentro do diretório /usr/local/src/foo. Depois de compilá-lo,
coloque os binários em /usr/local/bin/, as bibliotecas em
/usr/local/lib, e os arquivos de configuração em
/usr/local/etc.
Se seus programas e/ou arquivos realmente precisam ser colocados em algum
outro diretório, você ainda pode mantê-los em /usr/local/ e fazer
as ligações simbólicas apropriadas a partir do lugar necessário para sua
localização em /usr/local/. Por exemplo, você pode fazer a ligação
ln -s /usr/local/bin/foo /usr/bin/foo
De qualquer modo, se você obtiver um pacote cujo copyright permita redistribuição, você deve pensar em fazer um pacote Debian a partir dele, e enviá-lo para o sistema Debian. Guias sobre como se tornar um desenvolvedor de pacotes estão incluídos no manual de políticas da Debian.
A Debian usa o banco de dados terminfo e a biblioteca de rotas de
interfaces de terminal ncurses, ao invés do banco de dados
termcap e a biblioteca termcap. Os usuários que compilam
programas que necessitam de algum conhecimento da interface de terminal
devem substituir referências a libtermcap por referências a
libncurses.
Para dar suporte a binários que já foram ligados à biblioteca termcap
e para os quais você não possui o código fonte, a Debian oferece um pacote
chamado termcap-compat. Ele possui os arquivos libtermcap.so.2
e /etc/termcap. Instale esse pacote caso o programa falhe com a
mensagem de erro "can't load library 'libtermcap.so.2'"
("impossível carregar biblioteca 'libtermcap.so.2'"), ou
caso ele reclame da falta do arquivo /etc/termcap.
O AccelX usa a biblioteca termcap para a instalação. Leia
sobre termcap acima.
foo?
Essa mensagem de erro pode significar que o programa está ligado à versão
libc5 das bibliotecas do X11. Nesse caso você precisa instalar o
pacote xlib6, da seção oldlibs.
Sim. Mas você deve entender a política da Debian em relação a headers (cabeçalhos).
As bibliotecas C da Debian são construídas com as versões estáveis
mais recentes dos headers do gcc.
Por exemplo, a versão Debian-1.2 usava a versão 5.4.13 dos headers. Essa
prática contrasta com os pacotes do código fonte da kernel do Linux
distribuídos
em todos os sites de FTP do Linux, que usam versões ainda mais recentes dos
headers. Os headers distribuídos com o código fonte da kernel
estão em /usr/include/linux/include/.
Se você precisa compilar um programa com headers da kernel mais novos
que os oferecidos pelo pacote libc6-dev, você deve adicionar
-I/usr/src/linux/include/ à sua linha de comando quando quiser
compilar. Isto surgiu em um ponto, por exemplo, com o pacote do
automounter daemon (amd). Quando novas versões
da kernel mudavam algumas seções internas que lidam com NFS, o amd
precisava saber sobre elas. Isso obrigou a inclusão da última versão dos
cabeçalhos da kernel.