Re: Dificuldades com Empacotamento

Antonio, antes de mais nada eu gostaria de agradecê-lo muito por ter me
respondido. Está me ajudando demasiadamente. Fico muito grato mesmo!

Entendo o que diz quanto a política do Debian não permitir que determinado
aplicativo de um pacote altere arquivos de configuração relacionados a
outros pacotes. No entanto, acredito que já houveram exceções a essa
política, ou que em alguns casos ela não foi levada em consideração, visto
que já existiu no Debian pelo menos um pacote (pelo que me recordo agora)
com características parecidas com o meu. Refiro-me ao "likewise-open"
(atual "PowerBroker") que tem justamente este propósito de fornecer uma GUI
ou um utilitário CLI para automatizar as edições em determinados arquivos
de configuração e habilitar o sistema a integrar-se a um domínio AD.

Por favor, não me entenda mal, mas eu realmente não acredito que isso possa
ocasionar um problema, pois esses arquivos são disponibilizados em seus
pacotes originais com configurações mínimas, e os próprios desenvolvedores
dessas aplicações recomendam que os usuários façam modificações para
habilitar as funcionalidades da aplicação de acordo a suas necessidades. O
que o CID e outros afins fazem é apenas oferecer uma interface para edição
automática desses, reduzindo a etapa de configuração em que o próprio
usuário o abriria num editor de arquivos para fazê-lo linha por linha. Acho
que no máximo o que pode ocorrer é numa atualização desses pacotes o
arquivo de configuração editado ser substituído pelo arquivo disponível no
pacote mais recente, porém afetando somente as funcionalidades da aplicação
em questão, e não todo o sistema.

Agradeço também pela sugestão quanto ao versionamento do pacote. Vejo como
a medida mais cabível para resolver esse problema. No entanto, eu gostaria
de ter uma esperança de que com esses ajustes, o meu pacote poderia entrar
nos repositórios do Debian. Por enquanto a forma mais prática que encontrei
de disponibilizar o programa foi criando um PPA no launchpad para
distribuí-lo aos usuários do Ubuntu e distros derivadas. Se o amigo
enxergar essa possibilidade o agradeceria mais uma vez se me desse um
retorno.

Em 7 de julho de 2017 22:25, Antonio Terceiro <[email protected]>
escreveu:

> 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?
>



-- 

*Eduardo Moraes <https://www.linkedin.com/in/eduardo-moraes-b90a4a81>*

*Tecnólogo em Redes de Computadores*

*Tel/Whats:** (71) 9-8247-0103*

*Skype:** emoraes25*