Quais são as alternativas para a ESF?

Sou usuário do Linux há mais de 15 anos, mas uma coisa que odeio com paixão é a estrutura de diretórios obrigatória. Eu não gosto disso /usr/biné a lixeira para binários ou libs em /usr/lib, /usr/lib32, /usr/libx32, /lib, /lib32etc ... coisas aleatórias em /usr/shareetc. É mudo e confuso. Mas alguns gostam e gostos diferem.

Eu quero uma estrutura de diretórios onde cada pacote é isolado. Imagine se o dragão do media player tivesse sua própria estrutura:

/software/dragon
/software/dragon/bin/x86/dragon
/software/dragon/doc/README
/software/dragon/doc/copyright
/software/dragon/lib/x86/libdragon.so

Ou:

/software/zlib/include/zlib.h
/software/zlib/lib/1.2.8/x86/libz.so
/software/zlib/lib/1.2.8/x64/libz.so
/software/zlib/doc/examples/...
/software/zlib/man/...

Você entendeu. Quais são as minhas opções? Existe alguma distribuição Linux que use algo como o meu esquema? Alguma distro pode ser modificada para funcionar como eu quero (Gentoo ??) ou preciso do LFS? Existe alguma técnica anterior nesta área? Como publicações sobre se o esquema é viável ou inviável?

Não estou procurando pelo OS X. :) Mas inspirado no OS X é totalmente aceitável.

Edit : Eu não tenho idéia de como PATH, LD_LIBRARY_PATHe outras variáveis ​​de ambiente que dependem de um pequeno conjunto de caminhos devem funcionar. Estou pensando que, se eu tenho o editor do KDE Kate instalado /software/kate/bin/x86/bin/kate, não tenho problema em digitar o caminho completo para o binário para iniciá-lo. Como deve funcionar para bibliotecas e dlopenchamadas dinâmicas , não sei, mas não pode ser um problema de engenharia insolúvel.

Primeiro, um aviso antecipado de conflito de interesses: sou desenvolvedor de GoboLinux há muito tempo.

Segundo, uma reivindicação inicial de conhecimento de domínio: eu sou desenvolvedor de GoboLinux há muito tempo.

Existem algumas estruturas diferentes no uso atual. O GoboLinux possui um, e ferramentas como GNU Stow , Homebrew , etc, usam algo bastante semelhante (principalmente para programas do usuário). O NixOS também usa uma hierarquia não padrão para programas e filosofia de vida. Também é um experimento LFS razoavelmente comum.

Vou descrever tudo isso e depois comentar da experiência sobre como isso funciona na prática ("viabilidade"). A resposta curta é que sim, é possível, mas você realmente precisa .

GoboLinux

O GoboLinux possui uma estrutura muito semelhante à que você descreve. O software está instalado em /Programs: /Programs/ZSH/5.0.8contém todos os arquivos pertencentes ao ZSH 5.0.8, nos diretórios usuais bin/ lib/ .... As ferramentas do sistema criam links simbólicos para esses arquivos sob uma /System/Linkshierarquia, que é mapeada para /usr¹. A PATHvariável contém apenas o único diretório executável unificado e LD_LIBRARY_PATHnão é utilizada. Várias versões de software podem coexistir de uma só vez, mas apenas um arquivo com um determinado nome ( bin/zsh) será vinculado ativamente ao mesmo tempo. Você pode acessar os outros por seus caminhos completos.

Também existe um conjunto de links simbólicos de compatibilidade /bine , portanto, /usr/binmapeia para o diretório executável unificado e assim por diante. Isso facilita a vida do software em tempo de execução. Um patch do kernel, GoboHide, permite que esses links simbólicos de compatibilidade sejam ocultados nas listagens de arquivos (mas ainda podem ser percorridos).

Contra outra resposta, você não precisa modificar o código do kernel: o GoboHide é puramente cosmético e o kernel não depende dos caminhos do espaço do usuário em geral². O GoboLinux possui um sistema init sob medida, mas isso também não é necessário.

O slogan sempre foi "o sistema de arquivos é o gerenciador de pacotes", mas existem ferramentas razoavelmente comuns de gerenciamento de pacotes no sistema. Você pode fazer tudo usando cp, rme ln, no entanto.

Se você deseja usar o GoboLinux, é muito bem-vindo. Observarei, porém, que é uma pequena equipe de desenvolvimento e é provável que você descubra que algum software que você deseja não está empacotado se ninguém quiser usá-lo antes. A boa notícia é que geralmente é bastante fácil criar um programa para o sistema (uma "receita" padrão tem cerca de três linhas); a má notícia é que às vezes é desagradavelmente complicado, que abordarei mais abaixo.

Publicações

Existem algumas "publicações". Fiz uma apresentação no linux.conf.au 2010 sobre o sistema como um todo, que abrange tudo de maneira geral, disponível em vídeo: ogv mp4 (também no espelho Linux Australia local); Também escrevi minhas anotações em prosa. Existem também alguns documentos mais antigos, incluindo o famoso " Não sou sem noção ", no site do GoboLinux , que aborda algumas objeções e questões. Eu acho que estamos todos um pouco menos entusiasmados hoje em dia, e suspeito que uma versão futura será adotada /usrcomo o local base para os links simbólicos.

NixOS

O NixOS coloca cada programa instalado em seu próprio diretório /nix/store. Esses diretórios são nomeados com algo como /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/- existe um hash criptográfico que representa todo o conjunto de dependências e configurações que levam ao programa. Dentro desse diretório estão todos os arquivos associados, com locais mais ou menos normais localmente.

Ele também permite que você tenha várias versões ao mesmo tempo e use qualquer uma delas. O NixOS tem toda uma filosofia associada a ele: configuração reproduzível: ele basicamente possui um sistema de gerenciamento de configuração desde o início. Ele conta com alguma manipulação ambiental para apresentar o mundo certo de programas instalados ao usuário.

LFS

É bastante simples passar pelo Linux From Scratch e configurar exatamente a hierarquia que você deseja: basta criar os diretórios e configurar tudo para instalar no lugar certo. Já fiz isso algumas vezes na criação de experimentos do GoboLinux, e não é substancialmente mais difícil do que o LFS comum. Você precisa fazer os links simbólicos de compatibilidade nesse caso; caso contrário, é substancialmente mais difícil, mas o uso cuidadoso das montagens de união provavelmente poderia evitar isso se você realmente quisesse.

Sinto que havia uma dica do LFS sobre exatamente isso em um ponto, mas não consigo encontrá-la agora.

Viabilidade

A questão da ESF é que é um padrão, é muito comum e reflete amplamente o uso existente no momento em que foi escrito. A maioria dos usuários nunca estará em um sistema que não segue esse layout em essência. O resultado disso é que muitos softwares possuem dependências latentes que ninguém percebe, geralmente de maneira completamente involuntária.

Todos esses scripts com #!/bin/bash? Não é bom se você não tiver o Bash lá. É por isso que o GoboLinux possui todos esses links simbólicos de compatibilidade; é apenas prático. Muitos softwares falham em funcionar no tempo de compilação ou no tempo de execução em um layout não padrão e, em seguida, requer correção para corrigir, geralmente de maneira bastante intrusiva.

Seu programa básico do Autoconf geralmente se instala com facilidade onde quer que você diga, e é bastante fácil automatizar o processo de transmissão da maneira correta --prefix. Outros sistemas de construção nem sempre são tão agradáveis, intencionalmente inserindo-se na hierarquia ou levando os autores a criar configurações não portáteis. O CMake é um grande infrator na última categoria. Isso significa que, se você quer viver neste mundo, precisa estar preparado para fazer muito trabalho complicado nos sistemas de construção de outras pessoas. É um verdadeiro aborrecimento ter que corrigir dinamicamente arquivos gerados durante a compilação.

Tempo de execução é outra questão novamente. Muitos programas têm suposições sobre onde seus próprios arquivos, ou de outra pessoa, são encontrados em relação a eles ou absolutamente. Quando você começa a usar links simbólicos para apresentar uma exibição consistente, muitos programas têm bugs para manipulá-los (ou, às vezes, corrige comportamentos que não ajudam em nada). Por exemplo, uma ferramenta foobarpode esperar encontrar o bazexecutável próximo a ele ou em ../sbin. Dependendo da leitura do link simbólico ou não, esses podem ser dois lugares diferentes e nenhum deles pode estar correto de qualquer maneira.

Um problema combinado é o /usr/sharediretório. É para arquivos compartilhados, é claro, mas quando você coloca todos os programas em seu próprio prefixo, eles não são mais compartilhados. Isso leva a programas incapazes de encontrar ícones padrão e similares. O GoboLinux lidou com isso de uma maneira bastante feia: no momento da construção, $prefix/sharehavia um link simbólico para $prefix/Shared, e após a construção do link, foi apontado para o sharediretório global . Agora ele usa sandboxing em tempo de compilação e movimentação de arquivos para lidar com share(e outros diretórios), mas os erros de tempo de execução da leitura de links ainda podem ser um problema.

Conjuntos de vários programas são outro problema. O GoboLinux nunca fez o GNOME funcionar completamente, e também não acredito que o NixOS funcione, porque as interdependências de layout são tão complexas que é intratável curá-las todas.

Então, sim, é viável , mas:

• Há muito trabalho envolvido em apenas fazer as coisas funcionarem.
• Alguns softwares podem nunca funcionar.
• As pessoas vão te olhar engraçado.

Tudo isso pode ou não ser um problema para você.

¹ A versão 14.01 usa /System/Index, que é mapeada diretamente no /usr. Suspeito que uma versão futura possa descartar a hierarquia de Links / Índice e usá-la em /usrtodos os aspectos.

² Requer /bin/shexistir por padrão.

O GoboLinux (mencionado por F.sb) e o GNU guix são distribuições que usam uma estrutura de diretórios por pacote junto com links simbólicos para apontar para a versão "atual" de um binário.

O GoboLinux parece ser a melhor aposta se você deseja um sistema estável. O guix GNU diz explicitamente que ainda não está pronto para produção. O GoboLinux existe há anos. Eu também nunca tentei.

verifique o GoboLinux .

se você quiser que a estrutura de diretórios seja alterada, altere algum código do kernel, processo de inicialização, níveis de execução de diretórios com base em arquivos rc e gerenciador de pacotes, e depois a estrutura de diretórios.

O Linux FHS é baseado no que a Sun e outras empresas UNIX decidiram no final dos anos 80.

Uma mudança importante na época foi abandonar /usr/local/e introduzir /opt// { bin! lib! man! ...}

Se você está procurando a razão pela qual o / usr / bin hoje é usado como depósito de lixo, acredito que o GNOME é um dos projetos mais responsáveis.

O que aconteceu com as bibliotecas de 32 bits vs. 64 bits parece ser causado pelo FHS.

O Solaris introduziu subdiretórios específicos da plataforma em /lib /usr/bine /usr/lib. Faça o seu desejo é como a Sun aprimorou o conceito básico a partir de 1988.

Se cada pacote tivesse sua própria parte do sistema de arquivos, você precisaria de variáveis ​​de ambiente extremamente grandes e difíceis de manejar PATH, LD_LIBRARY_PATHe similares.

É claro que você pode instalar os pacotes dessa maneira e, em seguida, usar algo como Módulos GNU para gerenciar se eles estão no seu ambiente ou não, e é isso que fazemos para o software científico em que trabalho, mas não fazemos isso para software de sistema.