Alguns dias atrás, o líder do projeto Debian, Sam Hartman, apresentou as propostas para a votação da Resolução Geral do Debian a respeito da “diversidade de sistemas init”. Além disso, ele mostrou o quanto os desenvolvedores Debian ainda se importam, em 2019, em oferecer suporte a sistemas init não-systemd na distribuição Linux. Portanto, agora, o Debian adiciona outra opção para sistema init.
A resolução sobre sistemas init e systemd tinha três propostas: afirmar a diversidade init, systemd, mas apoiar a exploração de alternativas e focar no systemd para o sistema init e suas outras instalações. Agora, o Secretário do Projeto Debian, Kurt Roeckx, acaba de transmitir uma quarta proposta.
Debian adiciona outra opção para sistema init
O desenvolvedor de longa data do Debian, Ian Jackson, criou uma quarta opção para a próxima votação: apoiar sistemas não pertencentes ao sistema sem impedir o progresso. Os princípios estabelecidos são os seguintes:
1. Desejamos continuar a oferecer suporte a vários sistemas init no futuro próximo. E queremos melhorar nosso suporte ao systemd. Estamos desapontados porque isso teve que envolver outro GR.
2. Cabe principalmente às comunidades de cada ecossistema de software manter e desenvolver seus respectivos softwares – mas com o suporte ativo de outros mantenedores e porteiros, quando necessário.
DEPENDÊNCIAS DO SISTEMA
3. Idealmente, os pacotes devem ser totalmente funcionais com todos os sistemas init. Isso significa (por exemplo) que os daemons devem enviar scripts init tradicionais ou usar outros mecanismos para garantir que eles sejam iniciados sem o systemd. Isso também significa que o software de desktop deve ser instalável e, idealmente, totalmente funcional, sem o systemd.
4. Portanto, falhar no suporte a sistemas não pertencentes ao sistema, onde esse suporte não está disponível, é um erro. Mas * * não é um bug crítico ao lançamento. Se o requisito para systemd é registrado como um bug formal no sistema de erros do Debian, quando não há patches disponíveis, cabe ao mantenedor.
5. Quando um pacote tem funcionalidade reduzida sem o systemd, isso geralmente não deve ser documentado como Depende ou Recomenda (direta ou indiretamente) no systemd-sysv. Isso ocorre porque, com essas dependências, a instalação de um pacote pode tentar mudar o sistema init, que não é o que o usuário queria. Por exemplo, um daemon com apenas um script de arquivo de unidade systemd ainda deve ser instalável em um sistema não systemd, pois pode ser iniciado manualmente. Uma conseqüência disso é que, em sistemas que não são do sistema, pode ser possível instalar um software que não funcionará ou não funcionará corretamente, devido a uma dependência não declarada do systemd. Isso é lamentável, mas tentar mudar o sistema de inicialização do usuário é pior. Esperamos que melhores abordagens técnicas possam ser desenvolvidas para resolver isso.
6. Reconhecemos que alguns mantenedores consideram os scripts init um fardo e esperamos que a comunidade seja capaz de encontrar maneiras de tornar mais fácil adicionar suporte a sistemas init não padrão. Discussões sobre o design de tais sistemas devem ser amigáveis e cooperativas, e se forem desenvolvidos arranjos adequados, eles deverão ser suportados da maneira usual no Debian.
CONTRIBUIÇÕES DE SUPORTE NÃO SISTEMÁTICO SERÃO ACEITAS
7. Na falta de suporte a sistemas não pertencentes ao sistema, quando esse suporte estiver disponível ou oferecido na forma de patches (ou pacotes), * deve * ser tratado como um bug crítico de versão. Por exemplo: os scripts init * não devem * ser excluídos apenas porque uma unidade systemd é fornecida; Os patches que contribuem com suporte para outros sistemas init (sem efeito substancial nas instalações do systemd) devem ser arquivados como bugs com severidade ‘grave’. Isso visa fornecer um caminho leve, mas eficaz, para garantir que um suporte razoável possa ser fornecido aos usuários do Debian, mesmo onde as prioridades do mantenedor estão em outro lugar. (Invocar o Comitê Técnico sobre patches individuais não é sensato.) Se os patches forem eles próprios buggy RC (na opinião de, inicialmente, o mantenedor,
8. Os mantenedores de componentes do systemd ou outros gatekeepers (incluindo outros mantenedores e a equipe de lançamento) às vezes precisam avaliar contribuições técnicas destinadas a dar suporte a usuários que não são do systemd. A aceitabilidade para usuários de sistemas init não padrão, dos riscos de qualidade de tais contribuições, é uma questão para os mantenedores de sistemas init não padrão e para a comunidade ao redor. Porém, essas contribuições não devem impor riscos não triviais aos usuários da configuração padrão (sistema com Recomendações instaladas).
INSTALAÇÕES DO SISTEMA NÃO RELACIONADO À INIT
9. O systemd fornece uma variedade de facilidades além da inicialização do daemon. Por exemplo, criando usuários do sistema ou diretórios temporários. As abordagens atuais do Debian geralmente são baseadas em scripts debhelper. Em geral, abordagens mais declarativas são melhores. Onde – systemd fornece essa facilidade – existe uma especificação da instalação (ou subconjunto adequado) – a instalação é melhor do que as outras abordagens disponíveis no Debian, por exemplo, sendo mais declarativa – é razoável esperar que desenvolvedores de sistemas que não sejam do sistema incluem sistemas não Linux para implementá-lo – incluindo a consideração da quantidade de trabalho envolvido na instalação devem ser documentados na Política Debian (por incorporação textual, não por referência a um documento externo). A transição deve ser suave para todos os usuários. A comunidade não pertencente ao sistema deve receber pelo menos 6 meses, preferencialmente pelo menos 12 meses, para desenvolver sua implementação. (O mesmo vale para aprimoramentos futuros.) Se não for possível chegar a um consenso sobre políticas em tal instalação, o Comitê Técnico deverá decidir com base nos desejos do projeto, conforme expressos neste GR.
PADRÃO DE EXCELÊNCIA
10. Em geral, os mantenedores dos softwares concorrentes, incluindo os mantenedores dos vários sistemas init concorrentes, devem atender às necessidades de cada um. Isso inclui as necessidades e a conveniência dos usuários de configurações não padrão razoáveis.
11. Comentários gerais negativos sobre software e suas comunidades, inclusive sobre o próprio systemd e sobre sistemas init não-systemd, são fortemente desencorajados. Nem mensagens que expressam antipatia geral por systemd, nem predições do desaparecimento de sistemas não systemd são apropriadas para fóruns de comunicação Debian; do mesmo modo, referências a erros que não são relevantes para o tópico em questão. As comunicações nos fóruns Debian sobre esses assuntos devem ser encorajadoras e agradáveis, mesmo quando se discute problemas técnicos. Pedimos que a comunicação dos proprietários imponha isso estritamente.
12. Pedimos respeitosamente a todos os colaboradores do Debian, incluindo mantenedores, editores de políticas, equipe de lançamento, comitê técnico e líder do projeto, para perseguir esses objetivos e princípios em seu trabalho, e incorporá-los em documentos etc., conforme apropriado. (Esta resolução é uma declaração de posição em s4.1 (5).)
O texto para todas as quatro propostas acima pode ser encontrado no Wiki Debian antes da próxima votação.
Via Phoronix