On Tue, Jul 04, 2017 at 10:15:58PM -0300, Eduardo Moraes wrote: > Prezados, > > Procuro ajuda para resolver algumas dificuldades que estou tendo com meu > primeiro empacotamento, e para encontrar patrocinadores para meu pacote. > > Acredito que a dificuldade seja por conta do software que estou tentando > empacotar ter características bastante peculiares, onde eu estou tendo > dificuldades de explicar essas características as pessoas que até agora > tentaram me ajudar, muito por conta do idioma (inglês). Penso que tratando > com alguém do mesmo idioma ficaria mais fácil de elucidar determinadas > questões, e para que eu entenda melhor os meus erros, e possa corrigi-los. > > Para deixar mais clara a situação, tentarei fazer um breve resumo sobre o > programa em questão, e as informações pertinentes ao pacote: > > Upstream Name: CID (Closed In Directory) > Homepage: https://c-i-d.sourceforge.io > Documentação: https://sourceforge.net/p/c-i-d/documentation > Nº Bug (RFS): #864737 > > Resumo: CID é um programa em Shell Script com a finalidade de automatizar > configurações no Linux para que o sistema se comporte como uma estação > membro de um domínio Active Directory, usando por intermédio o Samba dentre > outros projetos de Software Livre. Basicamente, o programa oferece uma GUI > e um utilitário CLI que recebe os parâmetros básicos e faz automaticamente > toda edição dos arquivos de configuração necessários para esse fim seguindo > a documentação do Samba. No entanto, o programa tenta trazer como > diferencial alguns outros aspectos para fazer com que essa integração fique > ainda mais parecida com o funcionamento de uma estação Windows dentro desse > contexto, fazendo, por exemplo, uma combinação de módulos nos arquivos de > configuração do PAM para permitir que o sistema execute scripts de logon > armazenados no servidor de domínio durante a abertura de sessão do usuário; > e adicionando automaticamente usuários do grupo de administradores do > domínio a grupos de administração no sistema Linux, como o "sudo", por > exemplo. > > Problema: Não sei se entendi corretamente, mas a pessoa que tentou me > ajudar reclamou do fato do programa alterar arquivos de configuração que > pertencem a outros pacotes, e pelo fato dele alterar arquivos importantes > do sistema. Mas acredito que o que ficou como maior empecilho é o fato dos > scripts de manutenção do pacote (postinst e postrm) tentar trabalhar > arquivos que não pertencem a embalagem desse pacote em si. você entendeu certo. um pacote alterar arquivos de configuração de outros é uma violação da política Debian. > No entanto, a razão disso é que anteriormente o programa já era > distribuído em um pacote .DEB "caseiro" (criado manualmente com um > "dpkg -b"), porém colocando seus arquivos em lugares não apropriados > (segundo o FHS). Logo, a forma que encontrei para mover esses arquivos > aos locais adequados, ou mesmo fazer exclusões de arquivos que já não > serviriam na atual versão foi justamente com os scripts de manutenção. > Não sei se é correto, ou se teria alguma outra forma de resolver esse > problema, mas já pensei em reiniciar o projeto começando uma nova > contagem de versões, já que só agora pude adequá-lo melhor às > políticas utilizadas em algumas distribuições Linux, e em especial o > Debian. De qualquer forma, aguardarei por sugestões para tomar > qualquer decisão a respeito. provavelmente um projeto novo, um um pacote novo (e.g. cid2), é o melhor a se fazer. eu não entendo de samba (formatos de configuração, etc), então não tenho como dar nenhuma sugestão mais específica. em geral, quando você tem um pacote X e quer que outros pacotes possam configurar X, o ideal é que exista um diretório tipo /etc/X.d/, e que X leia *todos* os arquivos de configuração lá dentro, aí um pacote A pode criar /etc/X.d/A.conf, um pacote B pode criar /etc/X.d/B.conf, etc. note que você só precisa seguir a política Debian se você quer incluir o seu pacote no repositório oficial do Debian. se você quer apenas distribuir um .deb no seu site, você não é obrigado a seguir as regras do Debian. *porém*, leve em conta que a política Debian tem uma razão de ser. um dos motivos de não se alterar arquivos de outros pacotes é reduzir a probabilidade de um pacote quebrar o upgrade de outros pacotes. por exemplo: se eu instalto o CID no meu sistema Debian jessie, e faço o upgrade pra stretch, continua tudo funcionando direito?
Attachment:
signature.asc
Description: PGP signature