Amadeu Junior: Meu mestrado, parte 2: solução para empacotamento

Entendendo esse post

Requisitos

1. permitir instalação por usuário ou projetos (área compartilhada mas não global)
2. possuir resolvedor de dependências externas
3. permitir remoção mediante verificação de dependências = se remover X do qual Y,Z dependem então remove também Y,Z
4. possibilitar reuso da instalação já existente = se a biblioteca X já está instalada a resolução de dependência de qualquer Y deve reconhecer que X já está instalada
5. (idealmente) permitir sobrecarga e resolução de conflitos entre dependências que provém as mesmas interfaces/serviços
6. possuir API de alto nível para automatizar a instalação (pré e pós install), remoção (pré e pós remove), resolução de dependências e reconfiguração (restart de serviços)
7. permitir extensão da abstração de dependências para descrever dependências entre componentes SCS
8. suportar multiplataforma, no sentido de ter compatibilidade com o gerenciamento em plataformas não-UNIX
9. suportar multilinguagem, no sentido de gerenciar pacotes nas linguagens Lua, C++ e Java
10. permitir uso de repositórios de pacotes

Levantamento de características

• Critérios de comparação interessantes (por zeroinstall) : http://0install.net/links.html , http://0install.net/matrix.html

Projetos muito Interessantes

• EDOS + Mancoosi
  • http://www.mancoosi.org/edos/suggestions.html
  • http://www.mancoosi.org/edos/manager.html

haskell

1. Cabal ( http://www.haskell.org/cabal ): Cabal is a system for building and packaging Haskell libraries and programs It defines a common interface for package authors and distributors to easily build their applications in a portable way. Cabal is part of a larger infrastructure for distributing, organizing, and cataloging Haskell libraries and programs. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on.
2. Discussão sobre sistemas de build e packaging: http://www.nabble.com/Version-control-systems-td18827479i80.html
   1. Geoffrey Clemm, Odin Build Tool : http://portal.acm.org/citation.cfm?id=77607&dl=GUIDE&dl=ACM
   2. Walter F. Tichy, Smart Recompilation : http://portal.acm.org/citation.cfm?id=5959&dl=ACM&coll=portal

debian

1. building: dpkg-buildpackage e outros utilitários obrigam (?!) o uso de crosscompiling uma vez que pode ser difícil ter o dpkg-dev instalado em vários tipos de hosts
2. install: depende de arquivos em diretórios globais, mas pode usar diretórios por usuário = isso causa conflito com a instalação global
3. porte do dpkg para MS Windows : http://osdir.com/ml/linux.debian.ports.windows/2007-12/msg00001.html
   1. usar mingw mesmo para compilar o dpkg ou ao menos a libapt
4. porte da infra-estrutura debian para Interix (SFU/SUA) - veja abaixo na seção sobre compatibilidade com Windows
   1. em que ponto exatamente se encontra o resolvedor de dependências? É possível reusar o parser do control e o resolvedor de dependências?
5. implementar um módulo Lua frontend para dpkg semelhante a dpkg-ruby + libdpkg-ruby1.8 (depende de dpkg instalado)
   1. É possível tornar o parser do control e o resolvedor de dependências um módulo Lua?
6. motivação cross-compiling: ter bibliotecas nativas para o windows usando o mingw para poder ser usadas junto com MSVC e ser redistribuídas com softwares windows nativos
   1. http://mingw-cross.sourceforge.net/
   2. http://gnuwin32.sourceforge.net/summary.html
7. discussões sobre cross-compiling com mingw:
   1. http://lists.debian.org/debian-mentors/2006/03/msg00115.html
   2. http://lists.debian.org/debian-mentors/2006/03/msg00216.html
   3. http://wiki.njh.eu/Cross_Compiling_for_Win32
   4. https://dev.njh6.de/svn/njh/any2deb/
   5. CFLAGS="-mms-bitfields -march=i386" CC=i586-mingw32msvc-gcc LD=i586-mingw32msvc-ld
8. discussao pessoal:
   1. dpkg-cross: renomeia nomes de pacotes no control, bem como os diretorios com nomes=nome_pacote. Exemplo: libtool.deb -- dpkg-cross --> libtool-w32-i586-cross.deb
   2. dpkg-buildpackage com modificação para mingw
      1. gera pacotes em nova arquitetura (w32-i586)
      2. gera pacotes prefixado em /usr/$(DEB_HOST_GNU_TYPE)
      3. dado que gera binários para w32-i586 então no porte do dpkg no windows precisa reconhecer esta arquitetura
      4. uma alternativa para não precisar fazer porte do dpkg no windows e ter um ambiente cygwin que instala e gerencia os pacotes nativos windows
      5. outra alternativa é fazer instalação remota (no filesystem windows) via compartilhamento samba e possivelmente precisando do schroot/chroot

nix

1. suporte a MS Windows via Cygwin
2. http://en.wikipedia.org/wiki/User:Gwern/Nix_Package_Manager , http://nixos.org/patchelf.html , http://nixos.org/nixpkgs.html
3. hash de pacotes baseado nos arquivos fonte antes do building do pacote
4. usa repositórios?
   1. sim, faz download a partir do nome do pacote (parecido com apt-get install)
5. segurança no compartilhamento entre usuários?
6. interopera com pacotes já instalados (.deb, .rpm)?
7. http://nixos.org/releases/nix/nix-0.11/manual

zeroinstall

1. sem suporte a MS Windows porque usa python.os.fork() e não há implementação disso para windows!
   1. provavelmente SFU/SUA/Cygwin resolvem este problema.
   2. fazer um wrapper para spawn para portabilidade : http://effbot.org/librarybook/os.htm
   3. http://www.python.org/doc/faq/windows/
   4. refatorar o zeroinstall para remover a necessidade do fork
2. detalhes do empacotamento : http://0install.net/injector-packagers.html
3. hash de pacotes baseado na árvore de diretório gerada pelo building do pacote
4. usa repositórios?
   1. descentralizado e não depende de repositórios
   2. impede uso de repositórios?
5. segurança no compartilhamento entre usuários?
   1. http://0install.net/sharing.html
6. interopera com pacotes já instalados (.deb, .rpm)?
   1. conversor de .deb para 0install : http://0install.net/deb2zero.html
   2. http://0install.net/injector-using.html
7. como remover um pacote?
   1. Currently, they can't. You (the admin) can delete directories from /var/cache/0install.net/implementations to save space (preferably not while they're being used ;-). Ideally, we should track which users have requested which programs and remove them automatically when no-one wants them anymore. (ver "questions" no link sharing)

ipkg

1. TODO olhar o site e o código para ver possíveis problemas de portabilidade : http://handhelds.org/moin/moin.cgi/Ipkg

luarocks

1. só coisas Lua ou não, se não então qual o nível de building possível
   1. permite uso dos backends: make, cmake, comando_qualquer (scons,installshield) ou module (módulos Lua)
   2. embora não seja concebido para instalar outros binários é possível que instale uma vez que permite uso de Makefile
   3. para ser compatível com autotools seria preciso definir um novo backend baseado no make atual
      1. Implementado um build.autotools e build.tecmake ainda preliminares, mas que são úteis para compilar pacotes como openssl, openldap, sasl
   4. suportar a instalação de pacotes de várias linguagens
      1. Natural é atribuir nomes parametrizados pela linguagem (like debian-policy to liblangXYZ) de suporte: lua, java, cpp
         1. Útil para os pacotes dos Componentes SCS uma vez que eles é que dependem de estar numa mesma linguagem, no caso das suas dependências externas a exemplo do openssl:
            1. BusAccessControl_lua.all.rock dependsOn lualdap_lua.rock dependsOn openldap.rock
            2. BusOiLConnector_cpp.x86.rock dependsOn liboilall_cpp.rock dependsOn lua
            3. MyComponent_lua.all.rock dependsOn openldap AND sasl2 AND lua
            4. PingPong.rockspec, PingPong_lua.all.rock dependsOn oil_lua AND scs_lua.all.rock
      2. Outra opção é estender as informações de plataforma para incluir linguagem para que o tratamento do perplatform_overrides cuide de instalar archs={*lua.x86*,*java.all*,*cpp.solaris*}
   5. suportar a carga em cada contêiner
      1. O instalador precisa informar qual a variável de ambiente apropriada para cada linguagem afim de montar o LUA_PATH, CLASSPATH ou LD_LIBRARY_PATH de forma que o método de loading da linguagem encontre o pacote com versão especificada, bem como suas dependências.
         1. LUA : luarocks no ato do require já busca do manifest.repository os contextos (formando package.path e package.cpath) e assim realiza a carga
         2. JAVA : ClassLoader precisa receber um classpath montado com os contextos da resolução de dependências,
         3. C/C++ : o contêiner para realizar a carga dinâmica (dlopen) precisa montar o contexto na variável LD_LIBRARY_PATH
         4. reuso do luarocks.deps pela comunicação contêiner <-> exnode:installer :

            self.ComponentLoader:setContext( installer:getContext(componentId,self.mylang) )

2. premake http://premake.sourceforge.net/writing_scripts

luadist

1. http://luadist.sourceforge.net - LuaDist? is a cross-platform distribution of the Lua programming language that includes networked module management and deployment of source based or binary modules. Unlike projects like LuaRocks? the main focus of LuaDist? is full automatization and standalone deployment including the management of external libraries on the Linux(UNIX), Windows and Mac platforms. Uses the CMake approach to build and parse automatic dependencies.
2. Muito interessante, mas:
   1. Permite instalação simultânea de múltiplas versões dos pacotes? Justificativa: precisamos manter instalado múltiplas versões dos pacotes Lua bem como das bibliotecas de sistema (podemos precisar da OpenLDAP? tanto na sua versão 2.1.x quanto 2.4.x).
   2. Permite outras formas de compilação além do CMake? Justificativa: muitas bibliotecas de sistemas podem precisar ser compiladas e provavelmente usa-se ferramentas de compilação diferentes (autotools, make personalizados, scripts personalizados, etc).
   3. Possui noção de árvores de instalação que permitem a gerência via arquivo de manifesto (como no LuaRocks? )? Justificativa: os arquivos de manifesto do luarocks permitem a adoção de várias árvores de instalação simultâneas (para várias plataformas, por exemplo), assim ao usar o comando do luarocks pode-se usar o parâmetro --to=/home/user/install-linux-x86_64/, por exemplo.
   4. É fácil manter um repositório ou mesmo usar a própria árvore de instalação como repositório? Justificativa: o LuaRocks? apresenta uma funcionalidade interessante que simplifica a gerência do repositório uma vez que basta ter na mesma árvore os pacotes src.rock ou .rock.

clickonce (MS Visual Studio)

1. ClickOnce Deployment: projetos C++ - http://msdn.microsoft.com/en-us/library/ms235287(VS.80).aspx , projetos C#/J# - http://msdn.microsoft.com/en-us/library/t71a733d(VS.80).aspx

Alternativas para compilação

Hamster

1. Can be used as a generic 'make replacement' for almost any project. It even contains a 'Try' method that has automake-like functionality (detecting whether some compilation would fail or succeed at build time). Support: gmake, scons, nmake. http://kotisivu.dnainternet.net/askok/hamster/
2. Interessante observação dos autores (parece-me que substitui/expande bem o Tecmake): For professional work I warmly recommend SCons, a Python-based build tool that knows how to rebuild when only build parameters have changed (makefiles don't do that). Even with makefiles, Hamster takes care of header dependencies automatically (no need to list your headers, or do 'make dep'). Hamster's API derives from that of SCons, and even the original name of the project was SCons/Lua.

Scons

1. http://www.scons.org , http://www.qandr.org/quentin/writings/debscons.html

Compatibilidade MS Windows

1. SFU --- evolução ---> SUA (SFU deve ser mantido até 2009!)
2. Diferenças entre Cygwin e ServicesForUnix (SFU)
   1. http://osnews.com/thread?16317
3. Impacto de desempenho do SFU (usar benchmarks do shootout.alioth.debian.org)
4. Introduction to Microsoft Windows Services for UNIX 3.5 : http://technet.microsoft.com/en-us/library/bb463212.aspx
5. Interopsystems open source tools : http://www.interopsystems.com/community/default.aspx
6. Windows Services for UNIX : http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx
7. SFU Warehouse : http://www.interopsystems.com/community/warehouse.aspx
8. SFU Installation : http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=896C9688-601B-44F1-81A4-02878FF11778&displaylang=en
9. Gerenciador de pacotes Interix (SFU) : http://www.interopsystems.com/community/pkg_install.htm
10. UNIX Interoperability integrated on Windows Server >= 2003 : http://blogs.msdn.com/sfu/archive/2007/04/12/services-for-unix-vs-windows-server-2003-r2-unix-interoperability.aspx
11. Blog do gerente de projeto do SUA/SFU : http://blogs.msdn.com/shan/default.aspx
12. Projeto do porte de Debian para Interix (SFU/SUA) : http://www.debian-interix.net
    1. Bug para criação da lista oficial do porte do Debian para Interix : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441094
    2. Problemas com a conta root <-> Administrator : http://gridengine.info/articles/2007/02/06/notes-about-grid-engine-on-windows
13. Outras opções:
    1. Usar mingw (site novo, versão nova - gcc4) por ser mais simples e menos dependente das tecnologias microsoft: http://www.mingw.org , http://gnuwin32.sourceforge.net/packages/libgw32c.htm

Outros links

• http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites
• http://developer.mozilla.org/en/docs/Building_on_Windows_with_SFU_(Interix)
• http://packages.debian.org/unstable/admin/feta
• !OpenLDAP porting to MinGW
• Discussão sobre MinGW, OpenLDAP e OpenSSL
• http://www.winkde.org/pub/kde/ports/win32
• http://www.mancoosi.org/reports - projeto europeu posterior ao EDOS sobre "_developing tools for the system administrator. We pursue two main avenues: 1. Develop mechanisms that provide for rollbacks of failed upgrade attempts; 2. Develop better algorithms and tools to plan upgrade paths based on various information sources about software packages and on optimization criteria (workpackages 4 and 5)_"

Compilação openldap,openssl via mingw no MS Windows

1. instala msys
2. instala regex
3. instala zlib
4. instala perl5
5. baixa openssl do cvs
   1. ln -s /mingw/include /usr/include
   2. ln -s /mingw/lib /usr/lib
   3. ./config --prefix=/mingw --openssl-dir=/mingw/openssl/ shared
   4. editar util/mklink.pl e definir symlinks_exists como FALSE para usar copia (pois symlink é dummy no MSYS)
   5. make
      1. faltando definicoes: CERT_SYSTEM_STORE_CURRENT_USER , CERT_STORE_READONLY_FLAG , CRYPT_KEY_PROV_INFO , CERT_STORE_PROV_SYSTEM_A (... a maioria deveria estar em wincrypt.h)
   6. versão 0.9.8h tem versão instalável: http://www.slproweb.com/products/Win32OpenSSL.html
6. baixa openldap 2.4.11

JavaBahia: JavaOne 2009 - Uma Visão Geral

Rafael Gomes: Quer incrementar sua palestra? PDFCube!

O PDFCube utiliza as APIs Poppler e OpenGL APIs para proporcionar  uma interação de um cubo 3D na transição das páginas de um documento PDF.

Sendo assim temos esse resultado:

Quer uma notícia melhor? Você usa Fedora 11? Se a resposta for sim é apenas instalar o PDFCube que está ...

Rafael Gomes: Blog atualizado!

Acabei de atualizar meu blog, com ajuda no meu próprio post. Se alguém notar algum problema, por favor, me reporte! Obrigado!

Wille Marcel: Apresentação do GCompris no III ENSL / IV FSL-BA

GCompris é um conjunto de aplicativos educacionais para crianças de todas as idades. Gravei o vídeo da palestra do III ENSL / IV FSL-BA em que o Frederico Guimarães apresentou o GCompris. O áudio tá bem ruim, mas acho que dá pra entender…

O vídeo também pode ser baixado no formato OGG Theora, neste link.

Site oficial do GCompris em português: http://gcompris.net/-pt-br-

Rafael Gomes: Vídeo do meu casamento

Como eu já havia publicado as fotos do casamento, segue agora o vídeo, claro que não é o definitivo, é apenas o que Anne (minha esposa) chamou de "aperitivo" :D

Segue abaixo:

Eita felicidade! :D