macOS: Aplicação em bundle em vez de escrever no /usr/local

[adbjesus]

Como o macOS não tem um gestor de pacotes standard, as aplicações costumam ser criadas em bundles contidos que apenas dependem deles próprios (ou de bibliotecas do sistema). Ao depender do /usr/local outras aplicações podem também lá escrever e acidentalmente escrever por cima de alguma biblioteca fazendo com que esta aplicação deixe de funcionar (ou vice-versa). Noto no entanto, que isto não deve ser muito comum dado as bibliotecas também terem versões.

Mas algo que possa ser mais problemática é o script /usr/local/bin/pteid_uninstall.sh apagar as bibliotecas da diretoria /usr/local/lib que esta aplicação utiliza. Ora se outras aplicações dependerem dessas mesmas bibliotecas ao apagar essas bibliotecas essas outras aplicações podem deixar de funcionar.

Para além disso pode haver outros problemas como o que o macports menciona na FAQ (https://trac.macports.org/wiki/FAQ#usrlocal), ou até algum problema de compatibilidade com o homebrew que utiliza diretamente o /usr/local.

Assim para mitigar estes eventuais problemas penso que seja melhor seguir a prática mais comum de conter todas estas bibliotecas, certificados, etc.. no bundle /Applications/Autenticação.gov.app. Isto iria ainda facilitar a desinstação da app que se estiver num bundle pode ser desinstalada usando apenas o storage management do macOS em vez de se ter de recorrer à linha de comandos.

Para referência, estes são todos os ficheiros que foram criados na diretoria /usr/local ao instalar a versão 3.3.0.

/usr/local/bin/pteiddialogsQTsrv.app/Contents/_CodeSignature/CodeResources
/usr/local/bin/pteiddialogsQTsrv.app/Contents/MacOS/pteiddialogsQTsrv
/usr/local/bin/pteiddialogsQTsrv.app/Contents/Resources/appicon.icns
/usr/local/bin/pteiddialogsQTsrv.app/Contents/Resources/empty.lproj
/usr/local/bin/pteiddialogsQTsrv.app/Contents/Info.plist
/usr/local/bin/pteiddialogsQTsrv.app/Contents/PkgInfo
/usr/local/bin/pteid_uninstall.sh
/usr/local/bin/apps.plist
/usr/local/bin/fc-cache
/usr/local/include/eidlib.h
/usr/local/include/eidErrors.h
/usr/local/include/eidlibcompat.h
/usr/local/include/eidlibdefines.h
/usr/local/include/eidlibException.h
/usr/local/etc/fonts/fonts.conf
/usr/local/var/cache/fontconfig/6181e2b97a72a1f31a258f29fdd98652-le64.cache-7
/usr/local/var/cache/fontconfig/b0a71e6bf6a8a1a908413a823d76e21f-le64.cache-7
/usr/local/var/cache/fontconfig/CACHEDIR.TAG
/usr/local/var/cache/fontconfig/c6cafe6b1a56ed8b739253d6df90ca6a-le64.cache-7
/usr/local/var/cache/fontconfig/84c0f976e30e948e99073af70f4ae876-le64.cache-7
/usr/local/lib/libpteidapplayer.2.0.0.dylib
/usr/local/lib/libxerces-c-3.2.dylib
/usr/local/lib/libpteiddialogsQT.2.0.0.dylib
/usr/local/lib/libpteidcommon.2.0.0.dylib
/usr/local/lib/libCMDServices.1.0.0.dylib
/usr/local/lib/libzip.5.dylib
/usr/local/lib/pteid_jni/pteidlibj.jar
/usr/local/lib/libopenjp2.7.dylib
/usr/local/lib/liblcms2.2.dylib
/usr/local/lib/libpng16.16.dylib
/usr/local/lib/libpoppler.67.dylib
/usr/local/lib/libssl.1.1.dylib
/usr/local/lib/libfreetype.6.dylib
/usr/local/lib/libpteidlib.2.0.0.dylib
/usr/local/lib/libpteidcardlayer.2.0.0.dylib
/usr/local/lib/libfontconfig.1.dylib
/usr/local/lib/libcurl.4.dylib
/usr/local/lib/libtiff.5.dylib
/usr/local/lib/libjpeg.8.dylib
/usr/local/lib/libcrypto.1.1.dylib
/usr/local/lib/libxml-security-c.20.dylib
/usr/local/lib/libpteidpkcs11.2.0.0.dylib
/usr/local/lib/libpteidlibj.2.0.0.dylib
/usr/local/share/certs/CartaodeCidadao001.der
/usr/local/share/certs/ECRaizEstado_MC.der
/usr/local/share/certs/CartaodeCidadao003.der
/usr/local/share/certs/CartaodeCidadao002.der
/usr/local/share/certs/CartaodeCidadao006.der
/usr/local/share/certs/CartaodeCidadao005.der
/usr/local/share/certs/CartaodeCidadao004.der
/usr/local/share/certs/BaltimoreCyberTrustRoot.der
/usr/local/share/certs/Usertrust_RSA_Certification_Authority.der
/usr/local/share/certs/Multicert_Root_01.der
/usr/local/share/certs/GlobalChambersignRoot-2008.der
/usr/local/share/certs/COMODORSACertificationAuthority.der
/usr/local/share/certs/cacerts.pem
/usr/local/share/certs/ECRaizEstado002.der
/usr/local/share/pteid-mw/www/AutenticacaoGov.html
/usr/local/share/pteid-mw/www/AutenticacaoGov_failed.html

[adbjesus]

Já agora sugeria também a criação de um bundle para Linux usando flatpak/appimage/snap para que mais facilmente se possa instalar a aplicação em sistemas Linux não oficialmente suportados.

[ACamposPT]

Olá @adbjesus , obrigado pelas tuas sugestões, vamos ter em conta em futuros desenvolvimentos, mas queria desde já deixar aqui algumas notas.

A Aplicação "Autenticação.gov" aka MW não é apenas uma aplicação independente. O MW é constituído pela aplicação GUI mas também por um SDK. A Aplicação GUI sim poderia estar num bundle mas o SDK teria sempre de estar disponivel para outras aplicações. Seria mais correcto se fosse /usr/lib/pteid-mw em vez de/url/local/lib, já temos isso pensado, mas o MW já esta no "terreno" à algum tempo, estas alterações relacionados com o tipo de packaging, local de instalação, tem sempre questões de retrocompatibilidade que temos de ter em conta. Temos de ter muito cuidado com estas alterações.

Quanto ao script /usr/local/bin/pteid_uninstall.sh apagar as bibliotecas e outras aplicações que dependam das mesmas bibliotecas do SDK ficarem sem funcionar, aqui tens razão. Vamos adicionar uma nota ao manual sobre esse tema.

Já agora sugeria também a criação de um bundle para Linux usando flatpak/appimage/snap para que mais facilmente se possa instalar a aplicação em sistemas Linux não oficialmente suportados.

Já existe um issue sobre este tema: https://github.com/amagovpt/autenticacao.gov/issues/5, passa por lá.

[adbjesus]

Obrigado pela resposta.

A Aplicação "Autenticação.gov" aka MW não é apenas uma aplicação independente. O MW é constituído pela aplicação GUI mas também por um SDK. A Aplicação GUI sim poderia estar num bundle mas o SDK teria sempre de estar disponivel para outras aplicações.

Efetivamente não tinha pensado neste ponto. Se calhar o melhor seria ter as duas coisas separadas de modo a facilitar os processos de instalação de cada uma. Isto é, ter um projecto para a SDK e outro para a aplicação GUI, sendo que a GUI dependeria da SDK obviamente.

Dando uma vista de olhos rápida no readme/manual, não me parece que seja fácil usar a sdk separada do resto da aplicação GUI, mas posso estar enganado.

Ter as coisas separadas, facilitava a introdução da sdk em qualquer projecto que a use, sendo que dessa forma um projecto a pode usar da maneira mais conveniente. De uma forma geral permitia a introdução da SDK em qualquer tipo de aplicação usando os mecanismos próprios dos build systems das linguagens (e.g. gradle para java, cmake/meson para c++, entre outros). Nota, não estou a sugerir que tenha de ser dado o suporte direto para estes build systems, mas que ter a sdk separada facilitava a introdução da mesma nesses build systems. Isto facilitava ainda a introdução da sdk num bundle para uma aplicação de macOS, ou outro sistema, (como a "Autenticação.gov"). Por último era também mais fácil o packaging da SDK nos diversos sistemas operativos.

Percebo no entanto que isto não seja uma mudança fácil não só por esta aplicação mas por questões de compatibilidade com outras aplicações que usem a SDK. Mas podia ser algo a considerar. Isto se calhar merecia o seu próprio issue, mas deixo ao vosso critério se é viável ou não.

Seria mais correcto se fosse /usr/lib/pteid-mw em vez de/url/local/lib.

Em macOS se calhar o mais normal fosse /Library/pteid-mw (ou eventualmente /opt/pteid-mw como se vê mais frequentemente em Linux).

o MW já esta no "terreno" à algum tempo, estas alterações relacionados com o tipo de packaging, local de instalação, tem sempre questões de retrocompatibilidade que temos de ter em conta.

Claro, percebo que não seja trivial.