Software Público Brasileiro

Reassigned to @danielhmarinho

Reassigned to @lucassevero

Essa spec é bem pequena, então não acho que tenha como fugir muito dos padrões. Devido à nossa discussão a respeito de criar macros pros paths dentro das specs, criei uma macro %{_gitlablibdir} para /usr/lib/gitlab. Não sei se é a melhor prática, e não faz muita diferença nesse spec em específico.

Outro detalhe é que o empacotamento feito a partir dessa spec falha se na vm (que todo mundo está usando) tiver com o ~/.rpmmacros que já vem nela. Se essa parte for comentada o empacotamento passa tranquilo:

#%__arch_install_post \
#    [ "%{buildarch}" = "noarch" ] || QA_CHECK_RPATHS=1 ; \
#    case "${QA_CHECK_RPATHS:-}" in [1yY]*) /usr/lib/rpm/check-rpaths ;; esac \
#    /usr/lib/rpm/check-buildroot

A respeito da refatoração do Makefile do gitlab-deps, temos que decidir se esses pacotes vão continuar em repositórios separados ou se irão pra dentro do repo do softwarepublico como aconteceu com colab-spb-plugin, colab-spb-theme-plugin e noosfero-spb. Acho que deve ser melhor passar tudo pro software público pois sempre que for refatorar spec provavelmente vamos mexer no Makefile, daí em repos separados são dois merge requests. @terceiro , eu não participei dessa discussão anteriormente (estou entrando nos devops agora) o que estou falando faz algum sentido?

faz sentido sim, pelo menos para os pacotes que são específicos do SPB tipo os *-deps.

colab, gitlab, e noosfero propriamente ditos claramente não são coisas que a gente quer ter no repositório do SPB. no colab-deps o pessoal tirou os tarballs do repositório, provavalmente a gente quer fazer algo parecido com os outros.

Entendido!

sim, no caso dos *-deps vamos ter que importar sem o histórico pra não guardar os tarballs no git.

@lucassevero como ficou está tarefa? Podemos fechar ela com base na nossa última conversa?

Status changed to closed