Repositório RPM do PostgreSQL reduz dependência do EPEL no RHEL
Devrim Gündüz, mantenedor do repositório RPM oficial do PostgreSQL, removeu a maior parte das dependências do EPEL em RHEL 8, 9 e 10. PostGIS, pgBackRest, patroni e dezenas de ferramentas Python agora instalam só com PGDG e os repositórios do próprio RHEL.
Por anos, instalar boa parte dos pacotes do repositório RPM oficial do PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → em RHEL (e suas rebuilds, como Rocky Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → e AlmaLinux) começava com dnf install epel-release. PostGIS, pgBackRest, pgcli, patroni, pg_statviz, ora2pg e dezenas de extensões puxavam pelo menos uma dependência do EPEL.
Segundo relato de Devrim Gündüz, mantenedor do repositório RPM do PostgreSQL (PGDG), publicado no Planet PostgreSQL, isso mudou nas últimas semanas. Em RHEL 8, 9 e 10, o stack GIS, as extensões mais populares e quase todas as ferramentas Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → do projeto passam a instalar usando apenas os repositórios PGDG e os repositórios do próprio sistema operacional (BaseOS, AppStream e CRB).
Para quem administra banco de dados em ambiente enterprise, essa é uma mudança de infraestrutura, não de feature: menos pontos de falha, menos exceção de firewall corporativo para liberar e um caminho de upgrade mais previsível.
Por que o EPEL virou um problema
O EPEL (Extra Packages for Enterprise Linux) é mantido pela comunidade Fedora e continua sendo um projeto sólido. O problema, segundo Gündüz, não é a qualidade do EPEL, e sim a dependência estrutural que ele criava no empacotamento do PostgreSQL:
O EPEL é um ótimo projeto, e isso não é uma reclamação sobre ele. Mas depender dele nos causava problemas reais.
EPEL is a great project, and this is not a complaint about it. But relying on it caused us real problems.Devrim Gündüz, mantenedor do repositório RPM do PostgreSQL
Os atritos listados no post são específicos de quem opera banco de dados em produção:
- Acesso bloqueado: muitas empresas só liberam o repositório do fornecedor do sistema operacional mais o PGDG, e não autorizam habilitar o EPEL por política interna.
- Ciclos de vida descasados: pacotes do EPEL são atualizados, recompilados com novos sonames ou descontinuados no cronograma próprio do EPEL, o que quebrava pacotes do PGDG sem nenhuma mudança do lado do PostgreSQL.
- Versões antigas com CVE conhecida: o EPEL 8 e 9 distribuem
hdf5nas versões 1.10 e 1.12, Apache Arrow 8 e 9, netCDF 4.7 e 4.8, todas defasadas em relação ao upstream. - EPEL 10 por minor release: o EPEL 10 segue as minor releases do RHEL 10 (10.2, 10.3...), o que dificulta saber qual pacote do EPEL o usuário efetivamente recebe.
O que mudou: GIS, extensões e ferramentas Python
O maior volume de trabalho foi no stack geoespacial. O GDAL dependia de mais de 20 bibliotecas do EPEL: hdf4, hdf5, netCDF, cfitsio, freexl, Apache Arrow, libkml, xerces-c, armadillo, libdeflate, GPSBabel e outras. Todas passaram a ser empacotadas pelo próprio PGDG, em versões mais recentes do upstream do que as que o EPEL distribuía, incluindo o Apache Arrow 26, que trouxe de brinde o driver Parquet para o GDAL.
Nenhum driver do GDAL foi removido nesse processo, o que o post destaca como contraste com uma mudança recente do próprio RHEL. PostGIS das versões 3.3 a 3.7, SFCGAL (agora compilado contra os pacotes próprios de CGAL), osm2pgsql e pointcloud deixam de precisar do EPEL em qualquer versão suportada do RHEL.
Fora do GIS, a lista de mudanças é extensa:
pgBackRestpassa a usarlibssh2empacotado pelo próprio PGDG (com os patches de CVE do Fedora), mantendo repositórios SFTP funcionando sem EPEL.pgsodiumepg_pwhashusamlibsodium,libargon2elibscryptpróprios; como efeito colateral, as funçõesipcryptdopgsodiumpassam a funcionar também em RHEL 8 e 9, e opg_pwhashganha suporte ascryptno RHEL 10.mongo_fdwepostgresbsonusammongo-c-driver1.30 compilado pelo próprio repositório.pg_topepgmonetadeixam de depender delibbsdecJSON.
O Python foi, segundo o próprio Gündüz, a parte mais trabalhosa. No RHEL 8, pgcli, patroni e outras ferramentas Python passam a rodar sobre um stack Python 3.12 construído inteiramente pelo PGDG. No RHEL 9, o stack do pgcli, o typing-extensions usado pelo psycopg 3 e o pillow (compilado contra libimagequant próprio) saem do EPEL. No RHEL 10, cerca de 35 módulos Python, de boto3 e pydantic a matplotlib e pandas, passam a ser mantidos pelo PGDG, cobrindo pg_statviz, patroni, barman, pgcli, pg_activity, pgldapsync, pghoard, rohmu e sshtunnel.
Como a convivência com o EPEL foi resolvida tecnicamente
A maior parte das novas bibliotecas é instalada sob prefixo próprio, como /usr/pgdg-hdf5 ou /usr/pgdg-libarrow. Os pacotes do PGDG encontram essas bibliotecas via rpath, sem usar arquivos em ld.so.conf.d e sem aparecer nos provides do RPM. Na prática, isso significa que os dois mundos não colidem: quem mantiver o EPEL habilitado continua usando as bibliotecas do EPEL para o que instalou de lá, enquanto os pacotes do PGDG usam as suas próprias.
No RHEL 10 a solução é diferente, porque um módulo Python só pode existir uma vez no sistema. Os pacotes python3.12- do PGDG tornam obsoletos os pacotes python3- equivalentes do EPEL, e seus números de release começam em 42, de forma que um dnf upgrade comum com os dois repositórios habilitados migra o sistema para os pacotes do PGDG automaticamente.
Há duas ressalvas documentadas que valem registrar antes de rodar o upgrade em produção:
python3-snappypassa da versão 0.7.2 do EPEL para a 0.6.1 do PGDG, porque o pacote do PGDG carrega um Epoch mais alto, o que no RPM prevalece sobre o número de versão.- Os pacotes do EPEL também tornam obsoletos os nomes equivalentes do PGDG, até a própria versão do EPEL; o PGDG mantém suas versões do RHEL 10 sempre iguais ou acima das do EPEL justamente para que uma atualização do EPEL não reverta a escolha.
O CRB (PowerTools, em versões anteriores do RHEL) continua sendo exigido como antes; essa parte não mudou.
O que ainda depende do EPEL
Nem tudo saiu do EPEL, e a lista do próprio autor é objetiva sobre o motivo: ou a dependência é um projeto grande demais para reempacotar, ou ela é EPEL-only por natureza.
| Pacote PGDG | Depende de | Observação |
|---|---|---|
| check_patroni, check_pgactivity, check_pgbackrest | nagios-plugins | monitoramento Nagios |
| plr, dbt2, dbttools | R | linguagem estatística |
| firebird_fdw, libfq | Firebird | banco de dados Firebird |
| tds_fdw, pgloader | FreeTDS | conectividade com SQL Server/Sybase |
| pg_snakeoil | ClamAV | antivírus |
| pgbadger | perl-Text-CSV_XS | análise de log |
| postgresql_autodoc | perl-HTML-Template | documentação automática |
| pgpool-II, pgmemcache (RHEL 10) | libmemcached-awesome | cache distribuído |
| pgcopydb (RHEL 10) | gc | coletor de lixo em C |
| pgmodeler (RHEL 9) | Qt 6 | modelagem visual |
Quem depende de algum desses pacotes e quer vê-lo migrar para fora do EPEL pode registrar a demanda no repositório pgdg-packaging/pgdg-rpms no GitHub; o próprio Gündüz pede retorno por lá, e o trabalho completo está documentado na issue 422 do mesmo repositório.
O que muda para quem mantém PostgreSQL em RHEL de produção
Essa mudança não altera nenhuma funcionalidade do PostgreSQL em si, mas reduz a superfície de dependências externas de um stack que, em ambiente enterprise, costuma passar por aprovação de segurança caso a caso. Três efeitos práticos valem a pena anotar:
- Menos aprovação de terceiros: empresas que só liberam o repositório do fornecedor e o PGDG deixam de precisar negociar a liberação do EPEL para instalar PostGIS, pgBackRest ou Patroni.
- Menos risco de quebra por ciclo de vida alheio: como as bibliotecas de suporte agora seguem o cronograma de release do próprio PGDG, uma atualização do EPEL não derruba mais uma extensão do PostgreSQL de uma hora para outra.
- Atenção ao upgrade no RHEL 10: como os pacotes Python do PGDG substituem os do EPEL via obsoletes, vale revisar scripts de provisionamento que fixam versão exata de pacote Python (como o caso do
python3-snappy) antes de rodardnf upgradeem massa.
O ângulo que fica em aberto é de quem opera pacotes não cobertos pela lista acima: Firebird, FreeTDS, R e Qt continuam puxando EPEL, então um dnf install epel-release segue sendo rotina em cenários específicos de integração entre bancos. Para o restante do stack mais comum, a dependência externa virou exceção, não regra.
Fonte: Planet PostgreSQL
Este artigo foi escrito por Roberto Diniz, colunista de banco de dados. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
PolarFS implementa lease Disk-Paxos para evitar split-brain em disco compartilhado
O PolarFS, sistema de arquivos por trás do PolarDB, passou a gravar um protocolo Disk-Paxos no próprio bloco compartilhado para garantir que só um nó escreva por vez. A mudança, descrita em post publicado em 24 de outubro de 2026, fecha uma falha que só travava dois processos no mesmo host, não em hosts diferentes.
