Sam Hartman, Líder do Projeto Debian, compreender as divergências associadas à entrega do pacote elogind como parte da distribuição. Em julho, a equipe responsável pela preparação dos releases inclusão do elogind no ramo de testes, pois este pacote entra em conflito com o libsystemd.
Lembre-se que fornece as interfaces necessárias para executar o GNOME sem instalar o systemd. O projeto foi fundado como um fork do systemd-logind, colocado em um pacote separado e livre de ligação aos componentes do systemd. Entre outras coisas, elogind fornece sua própria versão da biblioteca libelogind, que assume uma série de funções oferecidas no libsystemd e substitui esta biblioteca durante a instalação.
Os motivos do bloqueio foram um conflito com o pacote systemd e o perigo de substituir o libsystemd por um libelogind alternativo, que é completamente incompatível com a biblioteca fonte no nível ABI.
O pacote rotula elogind como conflitante com as bibliotecas do systemd, mas é inerentemente projetado para funcionar apenas sem o systemd, e entrar em conflito com o systemd é realmente benéfico porque evita que o elogind seja instalado por engano. Por outro lado, na sua forma atual, as tentativas via APT de atualizar a configuração do systemd para a versão com sysvinit e elogind resultam em com o APT não funcionando. Mas mesmo que essa deficiência seja eliminada, a transição do systemd para o elogind permanece impossível sem a exclusão dos ambientes de usuário já instalados.
Os desenvolvedores do elogind foram adapte o elogind para funcionar sobre o libpam-systemd padrão, sem usar sua própria camada libpam-elogind. A transição do elogind para libpam-systemd é dificultada pela falta de suporte ao conceito de fatias, mas os desenvolvedores do elogind não querem alcançar a conformidade total com a API e repetir exatamente todos os recursos do systemd, já que o elogind fornece apenas o mínimo funcionalidade para organizar logins de usuários e não tem como objetivo replicar todos os subsistemas do systemd.
A resolução dos problemas técnicos descritos deveria ser resolvida ao nível da interação entre a equipa de lançamento e os mantenedores do elogind e do systemd, mas o líder do projeto foi forçado a intervir porque as equipas não conseguiram chegar a acordo, o trabalho conjunto evoluiu para o confronto e a solução para o problema chegou a um beco sem saída, em que cada lado estava certo à sua maneira. Segundo Sam Hartman, a situação aproxima-se de um estado que exige uma resolução geral (GR), na qual a comunidade decidirá sobre sistemas alternativos para init e suporte para sysvinit com elogind.
Se os membros do projeto votarem para diversificar os sistemas init, todos os mantenedores estarão envolvidos no trabalho conjunto para resolver este problema ou desenvolvedores específicos serão designados para trabalhar nesta questão e os mantenedores não poderão mais ignorar um sistema init alternativo, permanecer em silêncio ou atrasar o processo.
Atualmente no repositório já 1033 pacotes que fornecem unidades de serviço para systemd, mas não incluem scripts init.d. Para resolver este problema forneça arquivos de serviço por padrão, mas prepare um manipulador que analisaria automaticamente os comandos desses arquivos e geraria scripts init.d com base neles.
Se a comunidade decidir que o Debian tem suporte suficiente para um único sistema init, ela não poderá mais se preocupar com sysvinit e elogind e focar apenas em arquivos unitários e systemd. Esta decisão impactará negativamente as portas que não usam o kernel Linux (, и ), mas ainda não existem tais portas no arquivo principal e elas não têm o status .
A vinculação ao systemd também tornará muito mais difícil mudar a direção da distribuição no futuro e limitará novas experiências na área de inicialização e gerenciamento de serviços. Manter o elogind em forma funcional é muito mais fácil do que excluí-lo e tentar adicioná-lo novamente. Cada opção de decisão tem prós e contras, portanto será necessária uma discussão completa de todos os prós e contras antes da votação.
Fonte: opennet.ru