Vivemos dentro de um Buraco Negro?

Posted on 20/03/202522/03/2025 by Guilherme Silva

Os Antecedentes

A Teoria da Relatividade Geral (TRG) de Einstein é o instrumento teórico que nos permite decrever a estrutura do espaço e da matéria nele contida, em larga escala. Ela é basicamente uma descrição da gravitação universal, associando o conteúdo material do espaço com a sua geometria, responsável pelo movimento das galáxias e aglomerados galáticos. Na TRG o conteúdo de massa-energia em uma região do espaço-tempo deforma esse espaço.

†: A homogeneidade significa que o espaço é “igual” idependentemente de onde se observe. Isotropia significa que ele é “igual” independentemente de qual direção se observe. Essa igualdade se refere principalmente ao conteúdo de massa-energia. Embora ela não seja observada localmente (pois temos planetas, sistemas solares e galáxias) ela fica cada vez mais bem definida em escalas ultra-grandes.

§: A Constante Cosmológica, embora abandonada por Einstein que a chamou de “the biggest blunder of my life”, se tornou muito importante mais tarde, principalmente para incorporar na cosmologia a “energia escura” e os efeitos quânticos associados ao vácuo.

✠: Em outras palavras, o espaço-tempo não é estático: ele está se expandindo hoje e pode, no futuro se expandir para sempre ou voltar a se contrair de volta para a singularidade inicial. A decisão entre um ou outro destino cósmico depende da densidade de massa observada.

Logo após a publicação de seu trabalho Einstein percebeu que suas equações de campo seriam apropriadas para descrever o universo como um todo. Sob a suposição de que o universo é homogêneo e isotrópico^† ele encontrou uma solução para suas equações que deveriam descrever, pelo menos grosso modo, o comportamente da matéria dentro do espaço. Surpreso ele verificou que não existiam soluções estáticas para suas equações. Ele tentou, por um tempo, forçar a existência desse universo estático introduzindo um termo que denominou de “Constante Cosmológica”^§, mas abandonou essas tentativas quando Hubble descobriu que as galáxias estão todas se afastando de nós, exceto algumas poucas que estão na nossa vizinhança^✠. Voltando no tempo essas galáxias estariam cada vez mais próximas, até estarem todos aglomeradas em um ponto muito denso e quente, a chamada singularidade inicial. Juntamente com as observações a TRG gerou o Modelo Cosmológico Padrão, conhecido como o modelo do Big Bang. Ela descreve como, partindo de uma explosão inicial monumental, o universo entrou em sua fase de inflacionária, um período de tempo em que ele se expandou rapidamente, aumentou muitas vezes de tamanho. O modelo é corroborado por diversas observações, como o afastamento da galáxias, a abundância dos elementos químicos, entre outras. Mas ele também apresenta perguntas e dificuldades. Entre elas: se, de fato, o universo teve início em uma gigantesca explosão ocorrida ha 13,7 bilhões de anos, o que provocou essa explosão? Ou, como uma explosão caótica pode ter gerado um universo bem organizado, relativamente homogêneo e isotrópico?

Mais tarde , após o fim da Primeira Guerra Mundial, o físico alemão Schwarzschild encontrou uma solução para as equações de Einstein para o caso de uma concentração esférica de massa, como ocorre com as estrelas. Com essa solução foi possível prever que estrelas com muita massa podem colapsar em regiões muito pequenas e quentes que hoje denominamos buracos negros, BNs. Isso pode acontecer, por exemplo, quando o combustível nuclear se esgota em uma estrela e seu material, atraído pela força gravitacional, colapsa até que regiões de densidade muito altas sejam formadas (teoricamente densidades infinitas), o que rompe a estrutura do espaço-tempo e forma buracos negros. Além da singularidade central do BN também existe o horizonte de eventos, uma região em torno da singularidade de onde nenhum objeto, nem a luz, pode escapar. As soluções de Schwarzschild, inicialmente para estrelas sem rotação, logo foram extendidas para o caso de estrelas que giram, uma situação mais realista. Estrelas com muita massa e com rotação geram BNs rotatórios.

Simulação em computador de um buraco negro com um disco de acreção gasoso (visto de lado) girando em torno de um buraco negro. A gravidade superforte distorce a luz daquele disco de maneiras estranhas. Jeremy Schnittman/Centro de Voo Espacial Goddard da NASA.

Um pouco depois da apresentação da TRG outra teoria surgiu para revolucionar o ambiente da física, a Mecânica Quântica (MQ). Essa teoria é importante na descrição de objetos pequenos, nas escalas atômicas e nucleares, e é necessária para a explicação de muitos fenômenos observados, como a interação entre radiação e matéria e propriedades dos materiais. Ela é usada, por exemplo, para a descoberta de quais elementos existem nas estrelas, no meio interestelar, inclusive sua temperatura e movimentação. A MQ é a principal teoria por trás da eletrônica moderna.

Tanto a TRG quanto o MQ são teorias, internamente coerentes e verificadas pela experimentação e observação. Elas não são meras hipóteses. No entanto, e apesar de seu sucesso, elas não são coerentes entre si. Não existe uma teoria da gravitação quântica apesar dos muitos esforços que vêm sendo realizados nesse sentido. Apesar do estado incompleto em que se encontram as teorias no presente, existem situações onde elas devem ser aplicadas juntas. Um exemplo são os próprios buracos negros e as partículas que paricipam de sua formação. Outro está bem ilustrado na teoria de Stephen Hawking que considerou o que acontece quando um par de partículas se forma nas vizinhanças do horizonte de eventos de um buraco negro, quando uma delas pode ser absorvida pelo BN e a outras escapar para o espaço ambiente.

Equações de campo da Teoria da Relatividade Geral

Equação de Schrödinger da Mecânica Quântica

A Hipótese

Uma hipótese cosmológica interessante, apesar de altamente especulativa, surgiu no contexto das tentativas de unificação da relatividade geral com a mecânica quântica, e da exploração das implicações cosmológicas dos buracos negros. Este é o conceito de que nosso universo poderia estar dentro de um BN, de que o nosso Big Bang estaria associado à formação da singularidade existente em um universo “pai” ou de dimensão superior. A hipótese foi denominada de Cosmologia de Buracos Negros (Black Hole Cosmology), alternativamente por Cosmologia de Schwarzschild.

O conceito não foi elaborado em um momento específico nem houve um cientista que possa ser chamado de “criador” da hipótese. Pelo contrário, ele foi surgindo aos poucos e explorado por vários físicos. Uma linha do tempo pode ser listada sobre sua origem e desenvolvimento:

Roger Penrose e Stephen Hawking realizaram trabalhos importantes sobre os “teoremas de singularidade”, nas décadas de 1960 e 1970. Eles não fizeram referências diretas de que nosso universo poderia estar dentro de um buraco negro, mas seus trabalhos forneceram a base matemática para entender as condições extremas que poderiam existir em buracos negros e no Big Bang.
A ideia foi proposta e ganhou alguma atenção na década de 1970 quando físicos como John Archibald Wheeler e Bryce DeWitt estavam explorando as implicações da gravitação quântica e a natureza das singularidades. Wheeler foi um dos primeiros a considerar a possibilidade de que buracos negros poderiam ter conexões com a criação de universos.
Um dos proponentes mais conhecidos da hipótese foi o físico teórico Nikodem Popławski que, em 2010, publicou um artigo com a sugestão de que o Big Bang poderia ser o resultado do colapso de matéria em um buraco negro em um universo de dimensão superior. Popławski propôs que a singularidade no centro de um buraco negro poderia ser uma “ponte” para um novo universo, uma ideia que ele chamou de “cosmologia do buraco de minhoca” (wormholes).
Lee Smolin, em seu livro “The Life of the Cosmos” (1992), propôs a hipótese da “seleção natural cosmológica”, na qual inúmeros universos poderiam “nascer” dentro de buracos negros, com leis físicas ligeiramente diferentes. Aqueles com as condições favoráveis para a geração de um novo universo prosperariam com tais, em uma espécie de “evolução” de universos ao longo do tempo.
Roger Penrose e Stephen Hawking realizaram trabalhos importantes sobre os “teoremas de singularidade”, nas décadas de 1960 e 1970. Eles não fizeram referências diretas de que nosso universo poderia estar dentro de um buraco negro, mas seus trabalhos forneceram a base matemática para entender as condições extremas que poderiam existir em buracos negros e no Big Bang.
O conceito ganhou corpo e amplo reconhecimento com o trabalho do físico teórico Nikodem Popławski que, em 2010, publicou um artigo com a sugestão de que o Big Bang poderia ser o resultado do colapso de matéria em um buraco negro em um universo de dimensão superior. Popławski propôs que a singularidade no centro de um buraco negro poderia ser uma “ponte” para um novo universo, uma ideia que ele chamou de “cosmologia do buraco de minhoca” (wormholes).
À partir de 2022, o Telescópio Espacial James Webb (JWST) passou a coletar observações que exigem a reconstrução de nossas noções sobre o universo primitivo. Entre elas está a verificação de que predominam galáxias que giram em um sentido, em restrição a outro. Como discutiremos, isso reforça a hipótese de que nosso próprio universo esteja dentro de um buraco negro.

A Hipótese se fundamenta sobre os seguintes conceitos:

Tanto o Big Bang quanto o centro de um buraco negro são descritos como singularidades, regiões do espaço-tempo onde a densidade da matéria se torna muito elevada em volume pequeno, na medida em que se formam. As altas temperaturas, e portanto a densidade de energia ultrapassam os níveis que podem ser seguramente descritos pela física atual. Em um buraco negro, a singularidade é o ponto de densidade infinita no núcleo. No Big Bang, a singularidade representa o início do universo, com densidade e temperatura infinitas.
Um buraco negro é cercado por um horizonte de eventos, uma fronteira além da qual nada pode escapar, nem mesmo a luz. Alguns teóricos propõem que o Big Bang estaria associado a seu próprio “horizonte de eventos” dentro do qual o universo se expande.
Quando uma estrela massiva colapsa para formar um buraco negro, ela cria uma singularidade, em seu núcleo. A hipótese sugere que essa singularidade poderia não ser inativa mas, em vez disso, poderia levar à criação de um novo universo em expansão, como o nosso.
A física dos BNs e a cosmologia são áreas onde a TRG e a MQ entram em conflito. Essa hipótese surge no contexto das tentativas de unir essas duas teorias, sugerindo que o colapso de um buraco negro em um universo poderia gerar um novo universo com suas próprias leis físicas.

A ideia é baseada no “raio de Schwarzschild”, também chamado de “horizonte de eventos”, uma região limite além da qual nada pode escapar do buraco negro. Ne caso o horizonte de eventos do nosso Universo poderia ser equivalente ao limite de um buraco negro dentro de um “Universo pai”. Além disso cada buraco negro em nosso próprio universo poderia ser uma porta de entrada para um “Universo bebê”. Esses Universos seriam invisíveis para nós, pois estariam separados por seus próprios horizontes de eventos, tornando impossível a troca de informações entre eles. Segundo Poplawski os BNs não se tornam singularidades infinitamente densas e sim pontos de transição para novas realidades.

Com essa descrição fica claro que essa é uma hipótese fortemente especulativa, apesar de interessante. Ela nasce exatamente no setor desconhecido da interface da TRG e da MQ. Por muito tempo se apresentou a crítica de que não existem observações que sustentem diretamente essa hipótese. Teremos mais a dizer sobre isso abaixo. Além disso a complexidade matemática envolvida é grande, exatamente porque requer uma descrição da interface entre TRG e MQ, algo que ainda não foi alcançado. As singularidades são regiões do espaço-tempo onde as leis da física conhecidas não se aplicam e, portanto, não está nada claro como elas poderiam gerar um novo universo.

Cosmologia de Buraco Negro Crédito da ilustração: Perimeter Institute for Theoretical Physics

Uma nota técnica (pode ser pulada em uma primeira leitura): O físico teórico Nikodem Popławski trabalhou com teoricas alternativas para a Relatividade Geral, em particular a gravitação com torção (ou teoria de Einstein-Cartan). Ele fez contribuições para a cosmologia e à física de buracos negros, e mostrou que na teoria de Einstein-Cartan a singularidade central em um buraco negro pode ser substituída por uma “ponte de Einstein-Rosen” (um tipo de buraco de minhoca) que levaria a outro universo. A torção do espaço-tempo, prevista na teoria de Einstein-Cartan, evitaria a formação de uma singularidade clássica. As pontes de Einstein-Rosen, propostas pela primeira vez por Albert Einstein e Nathan Rosen em 1935, são também conhecidas como buracos de minhoca e são soluções teóricas para as equações da relatividade geral que sugerem a existência de “conexões” no espaço-tempo ligando duas regiões distantes do universo ou até mesmo universos diferentes, no caso de teorias de universos múltiplos.Na relatividade geral clássica, a singularidade no centro de um buraco negro é um ponto de densidade infinita onde as leis da física não podem ser aplicadas.

No panorama teórico da gravitação com torção o colapso gravitacional de uma estrela massiva não resultaria em uma singularidade, mas em uma região de transição para outro universo. Ao invés de uma ruptura com o próprio conceito de espaço-tempo, a inserção da torção (um conceito da teoria de Einstein-Cartan), a singularidade pode ser evitada, substituída por uma região de transição suave.Popławski explorou a ideia de que o Big Bang (a explosão que resultou em nosso universo) poderia ter resultar do colapso de matéria em um buraco negro em outro universo. Embora todos esses conceitos sejam especulativos e não comprovados pela observação, eles geraram interesse e discussão na comunidade científica. A teoria de Einstein-Cartan é matematicamente consistente mas não amplamente adotada pela comunidade que prefere se ater à relatividade geral clássica. A ausência de informações sobre o que ocorre no interio dos BNs torna difícil testar essas hipóteses.

A torção é um termo que pode ser naturalmente inserido nas equações de Einstein, sem romper com nenhuma das pressuposições normais da teoria. Ela é uma medida da assimetria na conexão do espaço-tempo e descreve como o espaço-tempo pode se “torcer” além de se curvar. Enquanto a curvatura do espaço-tempo (descrita pela TRG) associa a gravidade à distribuição de matéria e energia, a torção insere o momento angular intrínseco (spin) das partículas como fonte de deformação.

Universo Holográfico

O conceito do universo holográfico é uma hipótese que sugere que o universo pode ser entendido como um holograma. Mais especificamente ela afirma que toda a informação contida em um volume de espaço pode ser representada por um modelo registrado na fronteira desse espaço. O conceito está baseado em áreas como a teoria (que é uma hipótese) das cordas, a gravidade quântica e o princípio holográfico.

A hipótese foi proposta inicialmente por Gerard ‘t Hooft e desenvolvida mais tarde por Leonard Susskind, entre outros. Em 1997 Juan Maldacena sugeriu que um universo dotado de campo gravitacional (como ocorre no nosso) em um espaço de dimensões superiores (com dimensões acima das 4 dimenensões de nosso espaço-tempo) pode ser equivalente a uma teoria de campo quântico sem gravidade em uma superfície de dimensão inferior.

A fronteira de uma bola de 3 dimensões é a sua superfície, que possue apenas 2 dimensões.

O princípio holográfico afirma que toda a informação contida em um volume do espaço pode ser codificada em sua fronteira, tendo, portanto, uma dimensão menor que a do espaço original. Portanto, no nosso caso, apesar de parecer tridimensional (+ 1 dimensão de tempo) pode ser descrito por uma teoria física em uma superfície bidimensional. Dessa forma ele promove uma redução dimensional, importante em um contexto da física onde diversos modelos foram propostos propondo um número mais elevado de dimensões.

O princípio holográfico oferece uma abordagem promissora para unificar a mecânica quântica e a relatividade geral, dois pilares da física moderna que ainda não foram completamente integrados. Ela também tem implicações para a física dos buracos negros, sugerindo que a informação sobre a matéria que cai em um buraco negro não é perdida, mas sim codificada em sua superfície (o horizonte de eventos).

O universo holográfico é um conceito muito interessante, com consequências importantes em nosso entendimento do cosmos. No entanto ele ainda enfrenta grandes desafios conceituais e matemáticos, além de que não existem evidências diretas que a sustentem. Ele continua a ser uma área ativa de pesquisa na física teórica.

Observações Recentes

Desde que iniciou sua operação em 2022, o Telescópio Espacial James Webb (JWST, da NASA) têm coletando inúmeras observações que desafiam nossas noções sobre o Universo primitivo. Recentemente surgiram observações que sugerem o inesperado: a possibilidade de que o próprio Universo esteja dentro de um buraco negro.

Muitas observações verificaram que a maioria das galáxias distantes giram na mesma direção. Em um universo aleatório seria esperado que metade (aproximadamente) das galáxias giram em uma direção, outra metade em outra, dado um sentido arbitrário. A observação, no entanto, mostra que aproximadamente dois terços deles giram em um sentido, enquanto as demais giram no sentido oposto. A observação é surpreendente e demanda uma explicação, pois sugere que o próprio universo teve uma origem em rotação, o que favoreceria a existência de um número superior de galáxias girando nessa mesma direção.

Estrelas em rotação, se colapsadas e por conservação do momento angular, formam buracos negros em rotação. Isso seria compatível com a especulação de que universos são formados dentro dos BNs rotatórios.

Galáxias Espirais observadas pelo JWST. Galáxias circundadas em vermelho giram na mesma direção que a Via Láctea. Galáxias circundadas em azul giram na direção oposta. Crédito da Imagem: Monthly Notices of the Royal Astronomical Society, 2025.

Explicação Alternativa

As medidas da velocidade de rotação da Via Láctea começaram a ser realizadas no início do século XX. Gradualmente se compreendeu que a galáxia tem velocidade relevante, principalmente se considerarmos o seu tamanho gigantesco. É preciso lembrar que essa velocidade angular não é uniforma e as velocidades de objetos na periferia da galáxia são altos, provavelmente devido à presença da matéria escura.

A hipótese de que o Universo esteja dentro de um buraco negro é muito interessante e pode abrir caminho para novas decobertas fabulosas. No entanto existe uma explicação alternativa para os dados do JWST. Alguns pesquisadores se lembraram que a Via Láctea, nossa galáxia, está também em rotação. Já se pensou que a rotação de nossa galáxia fosse muito lenta, insuficiente para afetar as observações de objetos distante. Entretanto, a observação indica que a galáxia gira com velocidade angular significativa, de forma que, talvez, seja necessário recalibrar os instrumentos que medem distâncias no cosmos. Uma recalibração afetaria nossa compreensão de fenômenos fundamentais, como a taxa de expansão do Universo e a idade de galáxias distantes. Algumas indicações existem sugerindo que esse seja de fato o caso, tal como a verificação de que foram detectadas galáxias que parecem ser mais antigas que o próprio Universo.

Conclusões

Podemos concluir que a hipótese do Universo de Buraco Negro é uma especulação teórica que serve como um exercício intelectual para explorar as conexões entre buracos negros, singularidades e a origem do universo. O estudo desse tópico pode contribuir para a formulação de uma teoria consistente dos domínios do universo com altas densidades de matéria e energia, portanto curvaturas extremas, existam em regiões tão pequenas que exigiriam uma descrição quântica. Em outras palavras, ele poderia ajudar para o estabelecimento de uma teoria quântica da gravitação. Como uma hipótese física ela deve oferecer métodos de ser submetida ao teste da expeimentação ou observação (mais comum na astrofísica). Se passar nos testes propostos ela se torna uma teoria que, por sua vez, deve ser capaz de realizar previsões sobre o que se pode encontrar no universo.

Supondo que as descobertas do JWST realmente apontam para um padrão de rotação das galáxias suporte o conceito da Cosmologia de Buraco Negro, pode ser necessário um reajuste completo dos conceitos atuais de Cosmologia Padrão. Se buracos negros podem dar origem a novos universos seremos forçados a aceitar um modelo de universo cíclico, onde novos cosmos emergem continuamente, muito diferente do atual modelo aceito de um universo que tem uma origem bem definida, embora seu destino final não seja bem definido.

Bibliografia

Videos

Vídeos em inglês. Clique em “Closed Caption” para legendas.

Ciência Todo Dia: Nós estamos dentro de um buraco negro?

Brian Cox: Is The Whole Universe Inside a Black Hole?

PBS Space Time: Could The Universe Be Inside A Black Hole?

Space Dust: Do We Live Inside A Black Hole?

Artigos de Divulgação na Internet

Afshordi, N.; Mann, R.; Pourhasan, R., Scientific American: The Black Hole That Birthed the Big Bang.
Flavia Correia, Olhar Digital: Could the universe be trapped inside a black hole?.
Discover: JWST Findings May Suggest Our Universe Exists Inside a Black Hole.
Live Science: Could Earth be inside a Black Hole?.
Science and Nature: Our Universe May Have Emerged from a Black Hole in a Higher Dimensional Universe.
Grunge: The Astonishing Scientific Theory That Says The Universe Might Be Inside A Black Hole.
SciTechDaily: Our Universe May Have Emerged from a Black Hole in a Higher Dimensional Universe
Phys.Org: The black hole at the birth of the Universe.

todos as páginas visitadas em março de 2025.

Trabalhos Acadêmicos Relevantes

Nikodem Popławski: Cosmology with torsion: An alternative to cosmic inflation.
Popławski propõe que o Big Bang pode ter sido o resultado de uma singularidade em um buraco negro em um universo de dimensão superior. Este trabalho é uma das bases teóricas para a hipótese de que nosso universo está dentro de um buraco negro.
Lee Smolin: The life of the cosmos.
Smolin explora a ideia de que buracos negros podem dar origem a novos universos, uma teoria conhecida como “seleção natural cosmológica”. Embora não seja exatamente a mesma hipótese, está relacionada.
Roger Penrose: Cyclic Cosmology and Conformal Infinity.
Penrose discute a possibilidade de universos cíclicos e como buracos negros podem desempenhar um papel na criação de novos universos.
Stephen Hawking e James Hartle: Wave Function of the Universe.
Este trabalho clássico explora a natureza quântica do universo e como singularidades de buracos negros podem estar relacionadas à origem do cosmos.

Livros Recomendados

Leonard Susskind: The Black Hole War.
Discute o princípio holográfico e a física de buracos negros, fundamentais para entender a hipótese de universos dentro de buracos negros.
Roger Penrose: Cycles of Time.
Explora a ideia de universos cíclicos e como buracos negros podem estar conectados à criação de novos universos.
Michael Talbot: The Holographic Universe.
Aborda o princípio holográfico e como ele pode ser aplicado à cosmologia, incluindo a ideia de que nosso universo poderia ser uma projeção de um buraco negro.

Conceitos relacionados

Esses tópicos estão intimamente ligados à hipótese de que nosso universo poderia estar dentro de um buraco negro:

Singularidades de buracos negros e o Big Bang,
Princípio holográfico,
Gravidade quântica em loop,
Multiverso e dimensões superiores,
Teoria das cordas e branas

Outros Artigos nesse Site

Devemos Acreditar na Ciência?
Teoria, Hipótese e Modelo em Física

O Céu pode cair sobre nossas cabeças?
Porque o Céu Noturno é escuro? (e por que isso é um paradoxo?)
Como se mede o afastamento da galáxias?
O Big Bang é o modelo correto do Universo?
Existem mais de um Universo?
O que é Matéria Escura?

Regex, Consulta Rápida

Posted on 22/02/202522/02/2025 by Guilherme Silva

Veja também:
Expressões Regulares (regex)
Expressões regulares no Python

Segue um resumo tipo cheat sheet para referência rápida sobre o uso de Expressões Regulares no Python.

Grupos de Caracteres

Padrão	casa com
`\w`	uma palavra comsposta de caracteres `a-z, A-Z, 0-9` e sublinhado (`_`)
`\d`	umúnico dígito `0-9`
`\s`	um espaço em branco incluindo `\t`, `\n` e `\r`
`.`	qualquer caracter exceto quebra de linha
`\W`	qualquer sinal exceto caracter alfanumérico e sublinhado
`\D`	qualquer caracter exceto um dígito
`\S`	qualquer caracter exceto um espaço em branco

Âncoras

Padrão	significa
`^`	início de uma string
`$`	fim de uma string
`\b`	posição definida como limite de palavra
`\B`	posição definida como não sendo limite de palavra

Quantificadores

Na tabela abaixo chamamos de “quantificadores gulosos” ou greedy, aqueles que englobam a maior parte de texto possível casando o padrão. Já os “quantificadores não gulosos” ou lazy, englobam a menor parte de texto que satisfaz o padrão.

Quantificadores gulosos	quantificadores não gulosos	casa com
`*`	`*?`	o elemento precedente zero ou mais vezes
`+`	`+?`	o elemento precedente uma ou mais vezes
`?`	`??`	o elemento precedente zero ou uma vez
`{n}`	`{n}?`	o elemento precedente exatamente `n` vezes
`{n, }`	`{n,}?`	o elemento precedente pelo menos `n` vezes
`{n, m}`	`{n, m}?`	o elemento precedente de `n` até `m` vezes

Conjunto e Faixas

Chamamos de faixas as ranges ou regiões delimitadas de um certo conjunto.

Padrão	casa com
`[XYZ]`	qualquer um dos elementos X, Y ou Z
`[X-Y]`	elementos na faixa de X até Y
`[^XYZ]`	qualquer elemento exceto X, Y ou Z
`[^X-Y]`	qualquer elemento exceto aqueles na faixa de X até Y

Capturando Grupos

Padrão	significa
`(X)`	Captura X como um grupo
`(?P<nome>X)`	Captura X e atribui a ele o nome
`\N`	Referencia o grupo capturado #N
`\g<N>`	sintaxe alternativa para referenciar o grupo capturado #N
`X \| Y`	casa X ou Y
`(X) \| (Y)`	casa o grupo (X) ou (Y)

Retrovisores

Em inglês se usa as expressões lookaround, lookbehind e lookafter para significar a busca por padrões dadas condições antes e depois do padrão regex. Chamaremos aui essas expressões de retrovisores.

Padrão	significa
`X(?=Y)`	casa com X se seguido por Y
`X(?!Y)`	casa com X se não for imediatamente seguido por Y
`(?<=Y)X`	casa com X se precedido por Y
`(?<!Y)X`	casa com X se não precedido por Y

Funções Regex

São funções do módulo re:

re.fullmatch()retorna um objeto Match se o padrão casa com a string inteira

Método	retorna
`re.search(padrao, texto)`	1º texto casado e sua posição, em qualquer parte do texto e em todas as linhas,
`re.match(padrao, texto)`	1º texto casado e sua posição, no início do texto e apenas na 1ª linha,
`re.findall(padrao, texto)`	retorna uma lista com todos os trechos encontrados,
`re.finditer()`	retorna um iterador com todos os trechos encontrados, não superpostos
`re.split(padrao, texto)`	parte o texto na ocorrência do padrão e retorna as partes,
`re.sub(padrao, sub, texto)`	substitue em texto o padrao por sub,
`re.subn(padrao, texto)`	similar à `sub` mas retorna tupla com nova string e número de substituições
`re.compile(padrao)`	compila e retorna um padrão regex pre-compilado

Flags ou sinalizadores Regex

Flag	alias	flag inline	significado
`re.ASCII`	`re.A`	`?m`	essa flag só é relevante para padrões em bytes^†. Ele faz com que `\w`, `\W`,`\b`, `\B`, `\d`, `\D` e `\S` casem com ASCII caracteres apenas, ao invés do casamento com Unicode.
`re.DEBUG`	N/A	N/A	a flag `re.DEBUG` provoca a exibição da informação de debug para o padrão compilado.
`re.IGNORECASE`	`re.I`	`?i`	faz busca independentemente do caso (maiúsculas/minúsculas). Portanto o padrão `[A-Z]` casa caracteres [a-Z] ou [a-z].
`re.LOCALE`	`re.L`	`?L`	só é relevante em padrões de bytes. Faz com que `\w`, `\W`, `\b`, `\B` e casamentos sensíveis ao caso dependente do locale do computador. Essa flag não é compatível com a flag `re.ASCII` flag.
`re.MUTILINE`	`re.M`	`?m`	essa flag faz com que as marcações `^`/`$` casem texto no início/final de cada linha em texto multi-linhas.
`re.DOTALL`	`re.S`	`?s`	essa flag faz com que o ponto (`.`) case todos as caracteres, inclusive newline. (Por default a marcação de ponto (`.`) casa qualquer caracter exceto newline).
`re.VERBOSE`	`re.X`	`?x`	essa flag permite que o padrão seja organizado em seções logicas, incluido a inserção de comentários.

Bibliografia

Aurelio.net: Regex
Aurelio.net: Expressões Regulares em Bancos de Dados SQL
Aurelio.net: Expressões Regulares no Python
Julio Cezar Neves: Expressões Regulares: Retrovisores
Python Docs: re — Regular expression operations
Wikipedia: Expressão Regular

A Ilusão da Adequação da Informação

Posted on 29/01/202529/01/2025 by Guilherme Silva

Todos os tópicos →

Ilusão da Adequação da Informação

“O conflito interpessoal está piorando, gerando aumento na raiva, na ansiedade e estresse geral. Nossa intenção era a de investigar esses mal-entendidos e ver se eles poderiam ser mitigados”.
— Angus Fletcher, coautor do estudo, teórico narrativo e neurofisiologista da Ohio State University.

Um estudo demonstrou a existência de um tipo de viés cognitivo, chamado Ilusão da Adequação da Informação, que ainda não havia sido descrito. Nesse estudo, os pesquisadores reuniram três grupos de pessoas, os sujeitos do estudo, e apresentaram a eles, de forma diferenciada, informações sobre um tópico controverso. O grupo A recebeu a informação parcial, contendo apenas um dos aspectos sobre o assunto pautado e que sugeriam um curso de ação na solução do problema. O grupo B também recebeu informação parcial, com outro aspecto diferente e apontado para uma tomada de decisão diferente. Quanto ao grupo C, eles receberam toda a informação disponível sobre o tema, contendo ambos os lados da informação. Em seguida, os pesquisadores perguntaram a todos os envolvidos que posição eles adotaram em relação ao assunto controverso, e que alternativa eles adotariam para resolver o problema. Além disso, consultaram os participantes sobre se eles precisariam de alguma informação adicional antes de formar uma opinião completa sobre o assunto.

O resultado foi o seguinte: a maioria das pessoas em todos os três grupos concluiram que tinham informações completas sobre o assunto, que conheciam todos os aspectos relevantes sobre o tema. Pessoas no grupo C, que de fato haviam recebido a informação completa, ainda que estivessem corretas, estavam presumindo esse fato pois não teriam como avaliar se existiam dados além daqueles a que foram apresentados. Pessoas dos grupos A e B, que receberam informações parciais, também presumiram ter conhecimento completo sobre o tema. Essa é, exatamente, a chamada ilusão da adequação das informações.

Além dessas perguntas iniciais, os pesquisadores também perguntaram às pessoas como eles se posicionaram sobre a questão, e se julgavam que os demais membros da pesquisa concordariam com eles em um debate. Evidentemente, aqueles que acreditavam possuir todas as informações sobre o tema formaram uma opinião concreta sobre ele, além de acreditam que todas as demais pessoas deveriam concluir da mesma forma e chegar às mesmas conclusões. Claro que, no caso desse experimento, as pessoas dos três grupos haviam recebido informações diferentes e chegaram a conclusões diversas. E, debatendo o assunto, essas pessoas não conseguiram alcançar uma visão comum de consenso.

Nota †: Nesse aspecto o viés de cognição descrito tem uma semelhança com o chamado Efeito Dunning-Krueger.

O grupo C, que recebeu informações sobres os dois lados da questão, teve uma reação diferente, uma posição mais comedida e, portanto, menos confiante. Elas construíram uma certeza menor sobre o tema em questão. Essas pessoas tinham um conhecimento maior sobre o tópico discutido e sabiam que existia mais de um lado para o assunto. Assim sendo, não seria estranho que eles suspeitassem de que novas visões poderiam ser apresentadas, o que torna mais difícil a tomada de uma posição definitiva. Essa pessoas apresentaram níveis de incerteza maior, enquanto as pessoas dos grupos A e B tinham total certeza de que apenas a sua própria conclusão faria qualquer sentido^†.

O artigo original pode ser encontrado em PLOS One, Hunter Gehlbach, Carly D. Robinson, Angus Fletcher, no link The illusion of information adequacy.

Consequências

Embora ainda não tenham surgido estudos completos sobre esse tema, não é difícil especular que o resultado desse experimento tem consequências importantes na compreensão do estado de radicalização e polarização dos dias modernos. A formação de bolhas na vida das redes sociais garante que as informações circulem de forma parcial, sendo extremamente difícil furar a bolha. Esses núcleos de divulgação de informações (verdadeiras ou não) alcançam limites muito além daqueles que vemos na vida social comum, não eletrônica. Relatos anedóticos, interpretações incorretas e até mesmo a falsidade deliberada para alcançar fins pessoais, econônimos ou políticos são espalhados e amplificados pela repercução nas mídias. O viés cognitivo que denominamos a ilusão de adequação da informação encontra terreno fértil para selecionar e espalhar informações que corroboram a crença comum do grupo. A necessidade individual por aceitação e apreço dos “amigos”, reais ou virtuais, completam o esquema. Junta-se a isso a influiência conjunta da maiorias dos outros viéses de cognição, como os descritos nos artigos Viéses de Cognição e Bonhoeffer, Comportamento Heurístico e Viéses de Cognição , nesse site.

Posicionamentos radicalizados dentro das bolhas levam os grupos a formarem opiniões e tomarem decisões baseados na informação parcial a que têm acesso, se unam contra indivíduos de posição diferentes, circulem entre si suas “verdades absolutas” e se radicalizem cada vez mais. As redes sociais se encarregam de servir de ambiente para essa divulgação e para insuflar o ódio, essencial para que seus usuários aumentem sua participação nas redes e passem nelas maior tempo.

“Quanto menos nosso cérebro sabe, mais confiante ele se torna de que sabe tudo o que precisa saber. Isso nos torna propensos a pensar que temos todos os fatos cruciais sobre uma decisão, pulando para conclusões confiantes e julgamentos decisivos, quando estamos perdendo as informações necessárias.”
— Fletcher, um dos autores do artigo

Consequências tecnológicas podem resultar desse estudo. A pesquisa mencionada não foi direcionada para aplicações tecnológicas, da interação entre máquina e usuário, nem em questões da segurança cibernética. Ela precisa ser complementada por experimentos adicionais, na busca de verificação do mesmo viés em áreas diversas da cognição. O gerencimento da informação, mecanismos de buscas e outros podem ser severamente afetados pela insuficiência cognitiva. De fato, qualquer dificuldade humana na tomada de decisões pode levar a vulnerabilidades e desafios legais, especialmente quando a tecnologia da informação está envolvida. O reconhecimento desse viés deve levar a investigações mais completas para analisar essas ameaças. As descobertas ressaltam a importância da “humildade da informação” e sugerem uma reavaliação das práticas de tomada de decisão onde dados são considerados críticos.

Narrativas

O médico neurologista Steven Novella, no Podcast The skeptics Guide to the Universe, Episódio #1007, apontou com bastante propriedade que qualquer relato feito por um indivíduo é sempre uma narrativa. Diferente do uso que vem se consolidando nos últimos tempos, especialmente no ambiente político brasileiro, uma narrativa não é um relato necessariamente falso ou forjado. Pelo contrário, ele é a exposição de uma experiência ou aprendizado que contém os viéses de cognição embutidos na pessoa que relata. É impossível que se alcance um nível de imparcialidade tal que a narrativa seja equivalente a “um relato completamente fidedigno^‡ do ocorrido ou existente”.

Nota ‡: Considerando nossa deficiência na captação de qualquer fenômemo por causa de nossas limitações sensórias, de interpretação e de memória, seria importante lembrar que:

não podemos confiar totalmente em nossa percepção sensorial;
não podemos confiar na interpretação que damos a algo percebido;
não podemos confiar na memória que retemos da experiência.

Narrativas são as histórias que as pessoas contam, oralmente ou gravadas por qualquer tecnologia, e estão coloridas por várias camadas de deformação. Ao ouvir (ou ler) um relato não podemos baixar a guarda do pensamento crítico em nenhum momento. Pessoas que apreenderam apenas um lado do relato terão sempre certeza de suas conclusões que, com quase toda a certeza, serão parciais quando não completamente errôneas. Para tornar mais complexa a nossa dificuldade em entender, não é demais lembrar que coisas e eventos do mundo real são multifacetadas. Quando lemos um livro ou assistimos a um documentário estamos nos informando sobre o ponto de vista de quem produziu o conteúdo. Essa será sempre uma narrativa. Claro que isso não significa dizer que todos os relatos, livros ou documentários possuem o mesmo grau de autoridade, ou de falsidade. Parece razoável afirmar que existem relatos mais completos e realistas, principalmente aqueles realizados por especialistas ou alguém que teve experiência direta do evento. Contra essa última afirmação trabalha a desconfiança com que muitas pessas hoje encaram a autoridade, principalmente acadêmica.

Mesmo que conheçamos um assunto em profundidade não é possível afirmar que temos todos os dados relevantes sobre aquilo. Em particular devemos estar alertas, e desconfiados, contra narrativas limpas e exatas, que não contemplam a dissenção e a possibilidade de erro. Pacotes de informações muito claros e unilaterais tendem a ser enganosos.

Alguns exemplos podem ilustrar o viés da ilusão da adequação.

Exemplos

Exemplo 1: O biólogo marinho inglês Alister Hardy, em 1960, propôs a hipótese do macaco aquático, sugerindo de que antepassados humanos divergiram da linha evolutiva dos demais grandes macacos, adotando hábitos aquáticos e vivendo por um período dentro d’água. A hipótese foi sugerida antes que as principais descobertas de fósseis de hominídeos fossem feitas na África Oriental, e argumentava que, impelidos pela competição com outras espécies, um ramo de macacos foi forçado a buscar alimentos no fundo do mar, se adaptando a características próximas as dos mamíferos aquáticos. Isso explicaria a ausência de pelos e bipedalismo nos humanos modernos. Elaine Morgan, uma escritora de divulgação científica, autora de vários livros sobre antropologia e evolução, defendeu essa hipótese em seus textos. Seu livro The Descent of Woman, publicado em 1972, foi um best-seller internacional e se tornou muito popular entre os leigos.

Qual é o nível de certeza que você tem sobre as coisas em que acredita? Você já parou para considerar quais são os fatores que te levaram a formar uma determinada opinião, ou adotar uma crença? Suas opiniões e crenças são baseadas em alguma consideração e estudo, ou são adotadas por instinto, ou apenas porque elas são a cultura de seu ambiente social e de sua família?

Apesar do apelo à mentalidade não treinada popular, os antropólogos nunca levaram a hipótese a sério, principalmente porque ela não é consistente com o registro fóssil. Em outras palavras, não existem evidências para dar suporte à hipótese. Entre outras coisas, as características humanas que ela tentava explicar evoluíram em épocas muito diferentes, o que não seria compatível com um único período aquático. Embora a hipótese do macaco aquático tenha sido fartamente desmascarada pela comunidade científica, sendo classificada como pseudociência, ela alcançou grande apelo popular desde a publicação de “Descent of Woman”. Morgan recebeu diversos prêmios e honrarias, e o leitor não cientista acredita que ela era uma cientista extraordinária e que foi a propositora da hipótese. Para complicar, as pessoas passaram a julgar que a recusa da comunidade científica em aceitar o conceito de macaco aquático estava baseada em ciúmes e conservadorismo, o que a impediu de avaliar corretamente a sugestão.

Exemplo 2: Outro exemplo interessante e mais conhecido é a afirmação de que a Terra é plana, já tratada nesse site no artigo Porque existem Terraplanistas. Baseados em leituras questionáveis do texto bíblico e nas medidas de Samuel Rowbotham, no século 19, um número extraordinariamente grande de pessoas passou a defender o conceito de que a descrição de um planeta esférico faz parte de uma conspiração global, talvez organizada pela NASA. Eles afirmam que a Terra é plana, que o Sol e Lua são “lanternas” que não se encontram muito longe do solo, que as estrelas são pequenos pontos brilhantes na abóbada celeste, e que a gravitação não existe. Eles preferem ignorar as inúmeras evidências que comprovam a esfericidade, inclusive a medida do raio da Terra feita pelo grego Eratostenes (276 A.C. – 194 A.C.). Ocasionalmente um terraplanista realiza uma medida que claramente demostra o erro de sua hipótese (embora poucos se deixem convencer por essa verificação).

O “terraplanismo” contém inúmeros apelos à mentalidade capturada e ignorantes dos viéses de cognição. Primeiro observamos o realismo ingênuo (melhor descrito abaixo). Quem olha do alto de uma montanha, ou do centro de uma grande planície verá uma extensa planície. A Terra parece plana por ser uma esfera enorme. Em segundo lugar, de posse de poucas informações, muitas delas errôneas, a pessoa adota uma crença forte, sustentada pela aprovação de seu grupo, e pela suposta “nobreza” de estar contra a maioria. Segue-se a completa descofiança que essas pessoas têm pela autoridade científica e acadêmica.

Terra Plana

Metacognição

Metacognição significa refletir sobre nossos próprios pensamentos, opiniões e crenças, usando introspecção. A avaliação constante de tudo o que foi construído no edifício do conhecimento é uma tarefa básica do método científico. A história mostra que abandonar conceitos arraigados e bem estabelecidos, em uma determinada época, é extremamente difícil. No entanto, o acúmulo de novas evidências apresentadas pela experimentação e observação termina por derrotar as barreiras do conservadorismo do pensamento. Não raro é necessário esperar que toda uma geração de pensadores e cientistas seja substituída para que novas mentes consigam assimilar e utilizar a inovação. No entanto, como indivíduos, podemos nos beneficiar do processo de metacognição, da introspeção sobre o estado de nossa consciência e das processos que usamos para agregar e processar novas informações. É útil conhecer, e saber identificar em nós, os processos de formação dos viéses de cognição e outras distorções da percepção humana. É vital saber que nossos cérebros, embora uma ferramenta poderosa e versátil, não é infalível. Ajuda compreender que os processos evolutivos não favoreceram cérebros que questionam e desejam conhecer melhor os processos da natureza e dos humanos.

Realismo Ingênuo

Toda a percepção é inerentemente subjetiva. O objeto percebido estará sempre colorido pelo ambiente subjetivo e cultural, racional ou não, do observador. Essa descoberta apoia a sugestão de somos guiados pelo “realismo ingênuo”, a crença de que a compreensão subjetiva de uma situação por um indivíduo é a verdade objetiva. Os estudos sobre o realismo ingênuo geralmente se concentram na forma como as pessoas podem ter compreensões muito diferentes em face da mesma situação. A ilusão de adequação da informação, por outro lado, mostra como as pessoas podem desenvolver compreensão totalmente diferente sobre um tema, se ambas estiverem expostas a informações parciais e insuficientes.

A tendência humana de acreditar que a informação obtida por meio dos órgãos sensoriais está imediatamente completa, e fornece uma descrição fidedigna do objeto percebido, é um viés muito básico que permeia praticamente todos os demais vieses de cognição. Esse é chamado, em psicologia, de Realismo Ingênuo, baseado no conceito filosófico e epistemológico de mesmo nome. Essa falha cognitiva leva as pessoas a acreditarem que todos os que discordam delas devem ser desinformadas, irracionais ou tendenciosas. O termo foi cunhado pelo psicólogo social Lee Ross e seus colegas na década de 1990, e está relacionado ao conceito filosófico de realismo ingênuo, uma forma de empirismo puro que sustenta que a percepção sensorial permite a obtenção direta de conhecimento dos objetos, sem a intermediação de processamento racional.

Através dos experimentos e observações, os psicólogos sociais propuseram que toda a percepção é inerentemente subjetiva. O objeto percebido estará sempre colorido pelo ambiente subjetivo e cultural, racional ou não, do observador. Nesse caso a palavra “ingênuo” não deve ser tomada como indicadora de tolice ou estupidez. Pelo contrário, é natural que se adote essa postura até que a instrospecção e a experimentação altere a nossa percepção de nós mesmos e do mundo.

Para descrever o efeito os psicólogos sociais propuseram três princípios básicos que alimentam o realismo ingênuo. De acordo esse modelo, as pessoas:

acreditam que sua percepção sensorial é uma visão clara e objetiva, sem preconceitos ou deformações;
esperam que todas as outras pessoas cheguem às mesmas conclusões se expostas às mesmas informações, se as interpretarem de modo racional.
supõem que os que não atingiram as mesmas conclusões são necessariamente ignorantes, irracionais ou tendenciosos.

Uma descrição um pouco mais completa do estudo realizado está apresentada abaixo.

O Estudo

No estudo, a equipe da Ohio State, da Universidade Stanford e da Universidade Johns Hopkins realizou uma entrevista online com 1.261 estadunidenses. Todos os participantes leram um artigo sobre uma escola fictícia onde o abastecimento de água era inadequado. O grupo A leu um artigo que continha a sustentação de que a escola deveria se fundir com outra escola, para garantir melhor fornecimento de água. O grupo B leu um artigo contendo argumentos sustentando que as escolas permanecessem separadas, enquanto se aguardava outras soluções para o problema. O grupo C era o grupo de controle, onde as pessoas tomaram conhecimento de argumentos pró e contra a fusão das escolas.

Eles descobriram que a maioria dos dois grupos que leram apenas os argumentos parciais, pró-fusão ou anti-fusão, acreditavam que tinham informações suficientes para tomar uma boa decisão sobre o que fazer. A maioria afirmou estar pronta para seguir as recomendações do artigo que leram. Aqueles que leram o artigo “pró-fusão” foram significativamente mais propensos a recomendar que as escolas se fundissem, enquanto os participantes “pró-separação” foram propensos a recomendar que as escolas permanecessem separadas. Cerca de 55% do grupo de controle recomendou a fusão das escolas.

Os participantes que tinham metade das informações também disseram que estavam convictos de que a maioria das outras pessoas tomaria a mesma decisão que eles. O grupo de investigadores chamou essa crença, de que estamos corretos mesmo na ausência de informações completas, de ilusão da adequação.

Terra Plana

Bibliografia

PLOS One, Hunter Gehlbach, Carly D. Robinson, Angus Fletcher: The illusion of information adequacy
Podcast: The skeptics Guide to the Universe, Episódio #1007.
Blog Neurologica, Steven Novella: Confidently Wrong
Phylos.net: Vieses de Cognição
Phylos.net: Viéses de Confirmação e Efeito Dunning-Krueger
SciTechDaily: The Confidence Illusion
Complex Discovery: The Illusion of Knowing Enough
Popular Science, Laura Baisas: Why people insist they’re correct without all the facts
The Decision Lab: Why do we believe we have an objective understanding of the world?

Bonhoeffer, Comportamento Heurístico e Viéses de Cognição

Posted on 04/01/202526/02/2025 by Guilherme Silva

A estupidez é um inimigo mais perigoso do que a maldade. Pode-se protestar contra o mal; ele pode ser exposto e, se necessário, evitado pelo uso da força. O mal sempre carrega consigo o germe de sua própria subversão, deixando pelo menos um sentimento de inquietação nas pessoas. Contra a estupidez, somos indefesos. Nem protestos nem o uso da força conseguem algo aqui; a razão cai em ouvidos surdos; fatos que contradizem o prejulgamento simplesmente não são considerados e a pessoa estúpida passa a criticar até os fatos irrefutáveis. A pessoa estúpida, ao contrário da pessoa má, está satisfeita consigo mesma. Irritável, ela se torna perigosa e pode partir para o ataque. Por isso é preciso ter uma precaução maior com o estúpido do que com o mal. Tentar persuadir a pessoa estúpida por meio da razão é insensato e perigoso.
— Dietrich Bonhoeffer (1906-1945)

Dietrich Bonhoeffer foi um teólogo, pastor e um membro importante da resistência contra o nazismo na Alemanha de Hitler. Além de seus textos sobre teologia, ele ficou conhecido por sua resistência contra a ditadura nazista, ao programa de eutanásia de Adolf Hitler e perseguição aos judeus, ciganos, comunistas e outros grupos. Bonhoeffer testemunhou a ascenção de ideias malignas, propostas pelo regime nazista, e como elas foram aceitas de forma estúpida pela sociedade alemã, que estava pouco interessada nos destino daqueles que foram prejudicados pelo regime. Ele foi preso em abril de 1943 pela Gestapo, mais tarde acusado de ter participado de um complô para assassinar Hitler. Julgado com outros conspiradores ele foi enforcado em 9 de abril de 1945, quando o regime nazista começava a colapsar. Muito do que Dietrich Bonhoeffer propôs para explicar e combater o alto nível de intolerância e obscutantismo dos alemães que deram sustentação ao regime autoritário nazista é útil para entender o que está acontecendo no campo cultural, social e político no mundo inteiro, inclusive no Brasil.

Segundo Bonhoeffer, estupidez é diferente da canalhice e da maldade. Ela não é uma falha no caráter, nem uma suspensão momentânea da razão. Pelo contrário, ela é uma parte da psicologia bem definida, construída progressivamente por meio do acesso deficiente à informação de qualidade, e estimulada pelo funcionamento heurístico da mente humana. O estúpido atribui veracidade à ideia mais inverossímil, à conspiração mais ridícula e à proclamação mais perigosa. E esse fenômeno é frequentemente visto nas redes sociais. O grande problema está em que vozes irracionais são contagiosas, viralizam e se espalham na sociedade que, eventualmente e com algum atraso, descobre com perplexidade como a ignorância é mais ameaçadora do que a própria maldade.

O que é Comportamento Heurístico

“Comportamento heurístico da mente humana” é a expressão usada para se referir ao uso de atalhos mentais usados pelos indivíduos na tomada de decisões rápidas , para a solução de problemas de modo eficiente. Esse comportamento faz parte da mente e cognição humanos normais, frequentemente empregados na solução de situações complexas, ou dadas informações incompletas, que exigem resposta imediata. Embora eles sejam eficazes para reduzir a carga cognitiva, liberando recursos mentais, eles também podem levar a vieses cognitivos e erros graves de julgamento.

O economista e psicólogo cognitivo Herbert A. Simon foi o responsável pela introdução do conceito de heurística, na década de 1950. Ele sugeriu que a racionalidade usada na tomada de decisões pode ser muito limitada, por diversos fatores. Na década de 1970, os psicólogos Amos Tversky e Daniel Kahneman ampliaram esse campo de estudo com suas pesquisas sobre viéses de cognição, introduzindo os modelos heurísticos específicos, uma área de estudos que vem sendo ampliada até hoje. Enquanto alguns argumentam que a preguiça pura está por trás do processo heurístico, isso poderia ser apenas uma explicação simplificada para o motivo pelo qual as pessoas não agem da maneira que esperávamos.

São alguns tipos comuns de heurísticas:

Heurística de disponibilidade, que consiste em fazer julgamentos baseados em exemplos vêm à mente com maior facilidade. Por exemplo, as pessoas tendem a superestimar o risco de acidentes com aviões porque tais eventos são impressionates, ficam gravados na memória e são fáceis de lembrar.
Heurística representativa, que leva as pessoas a julgar a probabilidade de um evento tomando como base a semelhança que eles têm com outros eventos populares e estereotipados. Por exemplo, existe a tendência a julgar que senhoras idosas usando um tom de voz tranquilizador são necessariamente confiáveis e bondosas, embora a aparência não seja uma base de julgamento.
Heurística de ancoragem e ajuste, se refere à tendência das pessoas de confiar mais na primeira informação (a “âncora”) a que têm acesso. Por exemplo, em uma negociação para a compra de um produto, o lance inicial pode fixar pelo menos a faixa aceitável de preços. Esse viés pode tornar mais difícil a consideração de fatores adicionais inseridos posteriormente, nos levando a fazer más escolhas. Outro exemplo é a opinião formada por um visitante a um bairro que ele desconhece, se logo na chegada ele assiste a um evento violento e desagradável que pode ser associado à normalidade daquela região.
Heurística da escassez, que nos faz enxergar como mais valiosas as coisas mais escassas ou menos disponíveis. Profissionais de marketing usam com frequência essa heurística para influenciar as pessoas a comprar produtos. (“Oferta por tempo limitado” ou “enquanto durar o estoque”).
Heurística da tentativa e erro, que leva as pessoas a usarem diferentes estratégias para resolver um problemas, até que encontrem algo que funciona. Por exemplo, as pessoas usam tentativa e erro para jogar videogames, encontrar a rota de carro mais rápida para o trabalho ou para aprender uma nova habilidade. Evidentemente, tentativa e erro pode ser necessária em alguma situação mas, muitas vezes, um pouco de estudo e programação resolveriam o problema com mais eficiência.

Essas heurísticas são úteis em muitas situações, e são um mecanismo normal e válido do cérebro. Mas também podem levar a erros e vieses sistemáticos, o que mostra a importância de entendermos esses atalhos mentais para evitar o erro causado por eles na tomada de decisão.

Uma grande parte da necessidade da escolha baseada em heurística está assentada sobre a incrível dificuldade que o cérebro humano tem para lidar com fenônemos probabilísticos. Tversky e Kahneman reuniram pessoas para a realização de um teste, e deram a eles a seguinte descrição de “Linda”:

“Linda tem 31 anos, é solteira, franca e muito inteligente. Ela é formada em filosofia e, em seus tempos de estudante, sempre esteve profundamente envolvida com questões de discriminação e justiça social. Ela também participou de manifestações antinucleares”. Em seguida os participantes tinham que marcar qual era a declaração mais provável, em um conjunto de pares de afirmações. Entre as declarações estava esta:

A- “Linda trabalha como caixa em um banco”, e
B- “Linda trabalha como caixa em um banco e é muito ativa no movimento feminista”.

O que se verificou entre os entrevistados foi uma forte tendência para escolher B como a afirmação mais provável, por ela parecer mais descritiva do personagem Linda. No entanto, o conjunto descrito em B é um subconjunto de A, e não pode ser mais provável que ele. Em outras palavras: todos os caixas de banco que são feministas (B) são caixas de banco (A).

Manifestação de rebanho: Considerando a manifestação de “rebanho” da sociedade alemã, um dos vieses mais proeminente no comportamento de grupos, Bonhoeffer sugeriu que a estupidez é orgulhosa de si mesma, principalmente quando o indivíduo recebe a chancela do grupo, da “maioria”. Para ele, conhecer a natureza da estupidez é urgente para evitar ela predomine e cause danos graves à sociedade.

Existe um evento descrito pelo neurologista inglês Oliver Sacks sobre como foi a recepção do discurso do presidente dos EUA, Ronald Regan, transmitida pela TV e observado em um ambiente de um hospital psiquiátrico. Os pacientes com transtornos gerais de esquizofrenia e portavam dois tipos de disfunção cognitiva: aqueles com afasia global são incapazes de compreender os sentidos das palavras em seu sentido literal, e se apegavam aos aspectos não verbais do discurso; e aqueles com agnosia tonal, incapazes de compreender a expressividade da comunicação, sendo obrigados a se apegar ao texto literal da linguagem, de modo puramente semântico. Reagan não conseguiu persuadir ninguém daquele público restrito. Os pacientes se sentiram ultrajados, alternando suas reações entre risos e escárnio. Enquanto isso as pessoas ditas normais julgaram que Reagan era um grande comunicador, persuasivo e lógico.

Horrorizado com os absurdos da guerra e a aceitação tácita da sociedade alemã, Bonhoeffer passou a fazer oposição ferrenha ao grande grupo de cristãos que aderiram à ascensão do nazismo. Ele encontrou uma única explicação para o crescimento da intolerância e aceitação do regime totalitário que trouxe uma guerra total na Europa e no resto do mundo. Esse motivo era a estupidez – tornava-se urgente compreender a natureza dessa característica humana. Para isso era necessário se livrar da crítica moral: estupidez não é apenas falta de caráter. Na verdade, para ser estudada com consideração objetiva e científica ela deve ser tratada como uma categoria psico-sociológica.

A estupidez tem raízes profundas no psiquismo, impulsionada pelo funcionamento básico da experiência humana e o fato de que humanos são animais sociais. A própria sociabilidade está na base da estupidez. Pessoas que vivem isoladas, por qualquer motivo, estão menos vulneráveis a esse problemas, o que reforça a natureza social da estupidez. Um indivíduo pode agir de modo estúpido sem afetar seu ambiente social. Mas, quando a estupidez se difunde e é adotada pelo grupo, o indivíduo fica gravemente afetado, gerando um efeito de realimentação. O comportamento de rebanho é uma das causas principais da estupidez.

Bonhoeffer afirmava que “o poder de um precisa da estupidez do outro”. Isso não significa que o intelecto e outras habilidades fiquem atrofiadas ou desapareçam. A observação do fenômeno parece mostrar que, sob a pressão crescente de grupo, os indivíduos são privados de sua independência pessoal e desistem, de modo mais ou menos consciente, de manter sua autonomia em relação ao ambiente opressor. “Pessoas estúpidas são frequentemente teimosas, o que não significa que sejam independentes” (Bonhoeffer). Essas pessoas têm a sua parte lógica do cérebro prejudicada, passando a agir como zumbis políticos e sociais. Eles se apegam a slogans, palavras de ordem e gritos de guerra de nível emocional.

Com essa constatação Bonhoeffer fornece elementos para se compreender a história exótica sobre Ronald Reagan, contada por Oliver Sacks. Aqueles pacientes psiquiátricos estavam concentrados em seu mundo interior, distantes do convívio social. Isso os tornou imunes à loucura coletiva do pensamento conforme à pressão de massa. Eles enxergaram Ronald Reagan como um ator canastrão que mal conseguia concluir suas falas, nem passava sinais de autenticidade ou credibilidade.

Viéses Cognitivos

O uso de processamento de informações por meio de atalhos mentais (a chamada heurística) são resultado de um processo evolutivo especial que nos permite atingir conclusões e julgamentos rápidos, muito úteis para a nossa sobrevivência. Mas a mesma faculdade pode se transformar em vieses de cognição de muitas formas, de desvios sistemáticos de lógica e decisões irracionais. São partes desses desvios os ruídos mentais, crenças infundadas, a escalada irracional de compromisso, que consiste em persistir em uma decisão prejudicial que já recebu muito investimento. Entre estes desvios, o comportamento de manada, de seguir a maioria, é o mais proeminente. Podemos facilmente imaginar situações em nosso passado evolutivo onde, dentro de um grupo frágil de pequenos mamíferos, se torna importante aceitar a decisão da maioria, tal como quando se foge de um predador. Se a informação é escassa vale a pena fazer o mesmo que todos os demais estão fazendo. No entanto, é muito claro que isso não é uma boa decisão em todas as situações, principalmente na modernidade.

O estudo da História revela inúmeras situações em que a maioria estava errada, e que seguir o bando pode trazer resultados catastróficos. Por isso Bonhoeffer enfatizava que lutar contra a estupidez é mais difícil do que combater o mal. É mais fácil discernir as atitudes maléficas, expô-las para a coletividade e encontrar parceria para combater o mal. A estupidez , por outro lado, é difusa. O indivíduo não parece estar prejudicando voluntariamente as pessoas a seu redor. Além disso elas sempre têm um grupo de apoio. Canalhice e má-intenção são falhas de caráter individual. A estupidez é um fenômeno coletivo.

Canalhas e covardes devem se esconder para tirar vantagens pessoais, muitas vezes gerando infortúnio individual ou coletivo com seu comportamento imoral. A estupidez gera uma situação de amoralidade. Estúpidos se orgulham da própria estupidez porque são chancelados pelo grupo. Eles sabem que não estão sozinhos, se apoiam no coletivo e podem pedir ajuda. Humanos temem a solidão, e permanecem em grupos não pelo poder hipnótico de seus líderes, como já foi sugerido, mas sim pelo vínculo formado com eles e outros de seus subordinados. As redes sociais tornaram esse problema muito mais grave, com o seu poder de formação de bolhas, de amplificação da mensagem por meio de seguidores fiéis e de robôs, criando grandes manadas tomadas por vieses cognitivos. Nas palavras de Umberto Eco, a Internet deu voz a uma “legião de imbecis”. A uniformização do pensamento e a rejeição da autoridade, principalmente de natureza científica e acadêmica, são terreno fértil para a propagação da teorias da conspiração, para ambientes de ódio à grupos minoritários e para a radicalização das bolhas que hoje são praticamente impossíveis de serem rompidas. Tudo isso sem esquecer dos oportunistas que, mesmo sem participar inteiramente da bolha, fazem uso dela para atingir seus fins econômicos e políticos.

Bibliografia

A mente é Maravilhosa, Valeria Sabater: A Teoria da Estupidez de Bonhoeffer
Café com Sociologia, Bonhoeffer, Dietrich: Teoria da Estupidez, 2023.
VeryWell Mind: What Are Heuristics?
Psychology Today: Heuristics
Wikipedia: Dietrich Bonhoeffer
Wikipedia: Heuristic (psychology)
Youtube, Matematizei, O que é a Teoria da Estupidez?

Voce pode gostar de ler também aqui no Phylos.net:

Gerenciador de pacotes Flatpak

Posted on 20/12/202420/12/2024 by Guilherme Silva

Todos os tópicos →

O que é Flatpak

Flatpak é um utilitário (um aplicativo) usado para a distribuição, instalação e gerenciamento de pacotes de software no Linux. Ele usa um sistema de sandbox que permite aos usuários rodar aplicativos em um ambiente de isolamento partial do resto do sistema. Flatpak é também o nome de estrutura usada para criar pacotes de desktop em muitas distribuições Linux. Sua força está em sua abordagem para a entrega de software. Ele remove restrições tradicionais e fornece uma resposta simples para programas de computador, independentemente da linguagem de programação, do hardware ou das das arquiteturas de softwares que eles usam. Essa flexibilidade garante que os construtores possam usar o flatpak sem questionar problemas de compatibilidade.

Muitos outros sistemas de gerenciamento de pacotes existem para os diversos sistemas operacionais. Para o Linux temos, por exemplo:

dpkg: usado pelo Debian, Ubuntu e seus derivados, distribuindo arquivos no formato .deb. Foi o primeiro a apresentar um mecanismo de resolução de dependências, usando o aplicativo APT do lado do usuário.
RPM: criado pela Red Hat, agora é usado por diversas distribuições como PCLinuxOS, Fedora, AlmaLinux, CentOS, openSUSE, OpenMandriva e Oracle Linux. RPM lida com pacotes .rpm, sendo a base de gerenciadores como apt4rpm, up2date (Red Hat), urpmi (Mageia), zypper (openSUSE), e dnf (Fedora, Red Hat e Yellow Dog Linux). Leia aqui as instruções de uso de DNF4 e DNF5.
Pacman: Usado no Arch Linux, Frugalware e DeLi Linux, é um formato de pacotes binários e comprimidos por tar. Os pacotes são gerenciados pelo utilitário makepkg.
Snap: um gerenciador desenvolvido pela CAnonical para o Ubuntu. Os pacotes, chamados snaps são gerenciados pela ferramenta snapd, usado por diversas distribuições. Como o flatpak também cria ambientes de isolamento dentro do sistema.
AppImage: não é propriamente um gerenciador de pacotes mas sim uma forma de distribuição de arquivos binários executáveis que podem ser redados em qualquer distibuição linux, sem a necessidade de ajusta para cada uma. As imagens em AppImages trazem contêm todas as dependências necessárias para a execução do aplicativo.

Conceitos básicos

Alguns conceitos são essenciais para a compreensão do flatpak. Ainda que existam aplicativos GUI para gerenciar os pacotes, é útil aprender os comandos na CLI (command line interface).

O que é Sandbox

sandbox é um mecanismo de segurança na computação, usado inicialmente no desenvolvimeto de softare para garantir que um código esteja logicamente isolado do sistema operacional do computador e outros aplicativos instalados. Ele contêm, em princípio, todas as dependências necessárias, embora existam sistemas em que parte dessas dependências pode ser encontrada no computador hospedeiro. Desta forma, é possível escolher exatamente as versões de cada dependência e outros recursos usados no desenvolvimento, evitando falhas e impedindo que vulnerabilidades se espalhem pelo sistema. O isolamento nas sandboxes significa que um processo externo a ela não pode interferir em um processo interno, e vice-versa.

Mais tarde, o mesmo conceito passou a ser usado para a própria instalação e execução de aplicativos nos computadores de usuários, criando ambientes isolados que restringem o seu acesso ao sistema operacional, limitando possíveis danos que um aplicativo malicioso ou com falhas de segurança pode causar. Essa é também uma forma de garantir que o aplicativo tenham acesso às dependências corretas e que a instalação de novos aplicativos não prejudiquem o sistema e os demais aplicativos instalados.

Cada aplicativo flatpak é criado e executado em seu próprio ambiente isolado (sandbox), que contém o aplicativo e todas as dependências necessárias para sua execução (runtime). Por default, o aplicativo só pode acessar a sua própria sandbox, embora seja possível dar permissões para seu acesso a arquivos de usuário, rede, soquetes gráficos e algns componentes do hardware. Alguns recursos, como outros processos em execução no host, são deliberadamente vedados. Em algumas situações alguns recursos dentro do sandbox precisam ser exportados para fora, para serem usados pelo host. Esses recursos são denominados “exportações”, incluindo o arquivo de desktop do aplicativo com seu ícone.

Sandboxes, máquinas virtuais e conteineres: Uma máquina virtual é um ambiente virtualizado (isolado dentro do sistema operacional) que simula um sistema operacional completo. Por sua vez, um container isola um aplicativo e suas dependências em um ambiente virtualizado, compartilhando no entanto o kernel do sistema operacional hospedeiro. Os três conceitos são semelhantes, cada um com características próprias e propósitos específicos. Enquanto uma sandbox é mais genérica e pode ser usada para executar diversos tipos de programas de forma segura, uma máquina virtual simula um sistema operacional completo e é ideal para testes e desenvolvimento de software. Já um container é mais leve e ágil do que uma máquina virtual, sendo mais adequado para implementação e execução de aplicativos de forma isolada.

Repositório

Um repositório de software, ou repo, é um local de armazenamento para pacotes de software. Geralmente eles possuem uma lista de aplicativos disponibilizados, juntos com os seus metadados e runtime (as depedências). Repositório de software são gerenciado por controle de versão, e trabalham junto com gerenciadores de pacotes que permitem instalar e atualizar e gerenciar pacotes no computador do cliente.

Alguns dos repositórios de pacotes flatpak são:

Flathub: o maior e mais popular repositório.
GNOME Software: repositório oficial para o GNOME, com aplicativos projetados para o ambiente GNOME.
KDE Discover: repositório oficial para o KDE, com aplicativos otimizados para o ambiente KDE Plasma.
Elementary AppCenter: do Elementary OS.
Manjaro Community Repository: para a distribuição Manjaro Linux.

O principal repositório de pacotes flatpak atualmente (em dezembro de 2024) é o Flathub.

O Flathub fornece listas separadas para pacotas Trending, Popular, New, Updated e Verified. Aplicativos verificados no Flathub são aqueles mantidos diretamente pelo desenvolvedor ou algum grupo autorizado ou aprovado por ele. Aplicativos verificados aparecem com um ícone azul na página de seleção. Também existem aplicativos publicados no Flathub pela comunidade ou por terceiros, não mantidos pelo desenvolvedor original. Esses apps não são elegíveis para verificação.

Repositórios do flatpak se comportam de forma semelhante aos repositórios Git: um repositório flatpak pode conter um ou vários objetos, e cada um marcado com sua versão, permitindo atualizações ou downgrades. Cada sistema flatpak pode ser configurado para acessar um ou diversos repositórios remotos. Se um repositório é declarado em um sistema, torna-se possível acessar o conteúdo do repositório remoto, pesquisando a baixando dele aplicativos e runtimes. Em uma atualização, novas versões de aplicativos e runtimes são baixadas dos remotos relevantes. Como ocorre com o Git, apenas as partes alteradas entre as versões são baixadas, tornando o processo muito eficiente.

O manual do flatpak fornece instruções sobre como construir repositórios: Hosting a Repository.

Runtimes, bibliotecas empacotadas e portais

Runtimes: runtimes (ou ambiente de execução) são o conjunto das dependências básicas usadas pelos aplicativos. Todo aplicativo é criado no contexto de um runtime, que deve ser instalado no sistema host para que o aplicativo funcione adequadamente. O flatpak cuida da instalação do runtime necessário. Vários runtimes, com diferentes versões, podem ser instalados e usados lado a lado. Runtimes são independentes de distribuição e versão, fornecendo uma base estável para que os aplicativos funcionem independentemente das atualizações do sistema operacional.

Bibliotecas empacotadas, (bundled libraries): Se um aplicativo exige dependências não contidas em seu runtime, elas podem ser empacotadas junto com o aplicativo. Dessa forma os desenvolvedores têm flexibilidade na escolha de dependências, permitindo o uso de (a) bibliotecas não disponíveis em tempo de execução; (b) bibliotecas com versões diferentes das disponíveis no sistema; (c) versões corrigidas de bibliotecas.

Portais: portais são um mecanismo usados pelos aplicativos para interagir com o host, a partir de sua sandbox. Eles permitem o acesso a dados, arquivos e serviços sem necessitar de permissões adicionais. São exemplos de recursos acessados por portais: abrir arquivos por meio de uma caixa de diálogo (seletor de arquivos) ou imprimir. Existem kits de ferramentas que oferecem suporte seguro e transparente para portais. Outras informações sobre portais podem ser encontradas em Permissões do Sandbox: Sandbox Permissions.

Flatpak, instalação e uso

Usamos aqui as seguintes convenções:
# linhas de comentários
$ linhas de código (input)
➡ linhas de saída (output)

Para instalar o flatpak em seu sistema, siga estas etapas:

# antes de instalar, atualize os pacotes do sistema atual
$ sudo apt update && upgrade      # no debian, ubuntu, etc 
$ sudo dnf update                 # no fedora

#  instale o Flatpak 
$ sudo apt install flatpak        # no debian, ubuntu, etc 
$ sudo dnf install flatpack       # no fedora
$ sudo zypper install flatpak     # no openSUSE
$ sudo pacman -S flatpak          # no arch linux
 
$ sudo apt install gnome-software-plugin-flatpak        # no debian, ubuntu, etc 
$ sudo dnf install gnome-software-plugin-flatpak        # no fedora

# para instalar os aplicativos precisamos adicionar o repositório remoto (flathub)
$ sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

# para verificar a instalação, podemos ver qual versão foi instalada
$ flatpak --version
➡ Flatpak 1.15.12

Para ver o procedimento de instalação para outras distros consulte Flathub Setup.

Se a instalação foi bem sucedida, podemos instalar pacotes flatpak. Instalações de aplicativos podem ser feitas apenas para o usuário (o app fica disponível apenas para aquele usuário) ou no sistema inteiro (o app fica disponível para todos os usuários do sistema). Abrimos o terminal e executamos:

# instalação global
$ flatpak install flathub com.jeffser.Alpaca
# após um pedido de confirmação a instalação é concluída

# para instalar apenas para o usuário (<remote> é o repositório, <name&gt nome do app)
$ flatpak install --user <remote> <name>
    
# se nenhuma mensagem de erro for emitida o aplicativo pode ser executado com
$ flatpak run <name>

Para encontrar o nome do aplicativo visitamos o repositório de pacotes no Flathub, onde uma lista de aplicativos será exibida. Digamos, por exemplo, que queremos instalar o Alpaca, um gerenciador de servidores de Inteligências Artificiais. Pesquisamos Alpaca e encontramos:

Comando para instalação: flatpak install flathub com.jeffser.Alpaca
Comando para executar o app: flatpak run com.jeffser.Alpaca

Portanto executamos o código:

# instalação global
$ flatpak install flathub com.jeffser.Alpaca

# para instalar apenas para o usuário logado
$ flatpak install --user flathub com.jeffser.Alpaca

Para evitar as perguntas de confirmação, respondendo yes (sim) para todas as perguntas, use o parâmetro -y:

$ flatpak install flathub com.jeffser.Alpaca -y

É possível, dependendo do sistema, que apenas o primeiro passo da instalação seja necessário e o aplicativo fique integrado ao sistema. Nesse caso basta abrir o menu utilizado e clicar em seu ícone.

Nota: se você tem diversos aplicativos para instalar, e o faz regularmente, para reinstalar e atualizar o sistema operacional, você pode armazenar um artigo de texto contendo os comandos de instalações, separados por &&. Para reinstalá-los basta copiar o texto e colá-lo no terminal. (A maioria dos terminais Linux recebem colagem da área de transfrência com CTRL-SHIFT-V.)

Por exemplo, para instalar o WPSOffice, Geany e Zed, cole no terminal:

flatpak install flathub com.wps.Office -y && 
flatpak install flathub org.geany.Geany -y &&
flatpak install flathub dev.zed.Zed -y

Desinstalação de pacotes:

Uma vez instalado um aplicativo, ele pode ser desinstalado (removido do sistema) com o seguinte comando:

$ sudo flatpak uninstall <nome do pacote/aplicativo>

# por exemplo, para desinstalar o alpaca
$ flatpak uninstall com.jeffser.Alpaca -y

# podemos usar o alias remove
$ flatpak remove <nome do pacote/aplicativo>

Nota: Na desinstalação deve-se usar o mesmo nome com que o aplicativo foi instalado.

Atualizando ou rebaixando a versão de pacotes

O flatpak fornece funcionalidade de atualização de aplicativos instalados através do seguinte comando:

# atualizar    
$ sudo flatpak update <nome do pacote/aplicativo>

# ex.: para atualizar o alpaca
$ sudo flatpak update com.jeffser.Alpaca

# para atualizar aplicativo instalado para o usuário apenas
$ flatpak update --user com.jeffser.Alpaca

Também é possível rebaixar a versão instalada de algum aplicativo. Suponha, por exemplo, que necessitamos de uma versão anterior do navegador Brave. Primeiro pesquisamos no repositório informações sobre o navegador, com remote-info --log flathub, onde podemos encontrar versões anteriores disponíveis.

# para ver informações sobre o Brave    
$ flatpak remote-info --log flathub com.brave.Browser
➡ Brave - Fast Internet, AI, Adblock
        ID: com.brave.Browser
       Ref: app/com.brave.Browser/x86_64/stable
      Arch: x86_64
    Branch: stable
   Version: 1.73.101
   [truncado]
 
    Commit: 852620f9b5998b4cbfd621cf523e4367ba80b517427c810b8166eb48aa9f50db
   Subject: version update (7d8acf2a)
      Date: 2024-11-20 17:56:11 +0000
  [truncado]

# escolhemos a versão update (7d8acf2a) e anotamos o código de commit
# fazemos o update para aquele commit  
$ sudo flatpak update \
      --852620f9b5998b4cbfd621cf523e4367ba80b517427c810b8166eb48aa9f50db \
      com.brave.Browser

Gerenciando repositórios

Para adicionar um repositório no flatpak usamos:

# adicionar repositório
$ sudo flatpak remote-add --if-not-exists [name] [location]

# ex: adicionar o repositório do FlatHub repository
$ sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

# depois de instalado podemos procurar um pacote no repo
# procurando o gimp
$ flatpak search gimp
➡ Name                   Description            Application ID                Version     Branch           Remotes
  GIMP User Manual       GIMP User Manual       org.gimp.GIMP.Manual           2.10        2.10            flathub
  GNU Image Manip…       Create images and...   org.gimp.GIMP                  3.0.0~rc1   stable          fedora,flathub
  GimpLensfun            Lensfun Gimp plugin    org.gimp.GIMP.Plugin.Lensfun   0.2.4       2-40            flathub
  Fourier                Fourier GIMP Plugin    org.gimp.GIMP.Plugin.Fourier   0.4.5       2-40            flathub
  [lista truncada]

# para instalar o GIMP do repo Flathub
$ sudo flatpak install flathub org.gimp.GIMP

Se existirem mais de um repositório adicionados as várias opções disponíveis serão exibidas, como mostrado no exemplo acima. Você pode escolher qual pacote instalar, e de qual repositório. No caso foi instalado o org.gimp.GIMP, obtido no repositório flathub. Se não houver ambiguidade o nome do reposiório pode ser omitido.

Podemos listar quais são os repositórios cadastrados localmente com o flatpak. Para isso usamos remote-list. Para remover um desses repositórios da lista usamos remote-delete:

# listar repos cadastrados (existem apenas 2)
$ flatpak remote-list
➡ Name    Options
  fedora  system,oci
  flathub system

# podemos remover um repo
$ flatpak remote-delete flatub

Se existirem aplicativos ou runtimes instalados à partir desse repositório, surgirá a opção de remover ou não esses apps. Para remover apenas o repositório, deixando os aplicativos inalterados, usamos:

$ flatpak remote-delete --force <nome-repositorio>

Permissões e Sandboxing

Por default os aplicativos Flathub podem ser instalados com permissões mais amplas que as exigida no sistema ou desejadas pelo usuário, para que um número maior de usuários sejam atendidos por essa instalação. Como exemplo, o Brave tem instalação default com –socket=pcsc (entre outras) para acesso por cartão inteligente. Se o usuário não tem um desses cartões ele pode desejar modificar as permissões para melhorar a segurança.

# para mostrar as permissões
$ flatpak info --show-permissions com.brave.Browser
➡ [Context]
   shared=network;ipc;
   sockets=x11;wayland;pulseaudio;pcsc;cups;
   devices=all;
   [truncado]

# alterar a permissão
$ flatpak override --user --nosocket=pcsc com.brave.Browser

# verifica o estado
$ flatpak override --user --show com.brave.Browser
➡ [Context]
  sockets=!pcsc;

# para ressetar todas as alterações
$ flatpak override --user --reset com.brave.Browser

Existem várias ferramentas GUI disponíveis, como Flatseal, GNOME Settings e KDE Settings, que permitem alterar essas permissões em um ambiente de janelas.

Aplicativos instalados e histórico de operações

Para listar os aplicativos e runtimes instalados com flatpack usamos flatpak list. Para listar apenas os aplicativos instalados, flatpak list --app e apenas os ambientes, flatpak list --runtime.

# lista de aplicativos e runtimes
$ flatpak list
➡ Name             Application ID                        Version
  Bitwarden        com.bitwarden.desktop                 2024.12.0
  Mesa             org.freedesktop.Platform.GL.default   21.3.9
  Brave            com.brave.Browser                     1.73.101
  Alpaca           com.jeffser.Alpaca                    2.9.0
  ZapZap           com.rtosta.zapzap                     5.3.9
  Sigil            com.sigil_ebook.Sigil                 2.2.0
  Zed              dev.zed.Zed                           v0.165.4
  Obsidian         md.obsidian.Obsidian                  1.7.7
  SiYuan           org.b3log.siyuan                      3.1.15
[a lista está truncada]

# lista apenas de aplicativos
$ flatpak list --app
➡ Name            Application ID               Version
  Bitwarden       com.bitwarden.desktop        2024.12.0
  Brave           com.brave.Browser            1.73.101
[a lista está truncada]

# lista apenas de runtimes
$ flatpak list --runtime
➡ Name                       Application ID                       Version
  Codecs                     org.audacityteam.Audacity.Codecs      stable
  Mesa                       org.freedesktop.Platform.GL.default   21.3.9
  GNOME App Platform v. 47   org.gnome.Platform                    47                  
[a lista está truncada]

Além das colunas mostradas ainda temos informações sobre Branch, Origin, Installation, não exibidas.

Para obter um histórico de operações realizadas com flatpak usamos:

$ flatpak history
➡ Time               Change           Application                           Branch      Installation     Remote
   Dec 13 11:08:56   add remote                                                          system          fedora
   Dec 13 11:08:56   add remote                                                          system          fedora-testing
   Dec 13 11:10:42   add remote                                                          system          flathub
   Dec 13 11:57:21   deploy install   org.freedesktop.Platform.GL.default    23.08       system          flathub
   Dec 13 11:57:24   deploy install   org.freedesktop.Platform.GL.default    23.08-extra system          flathub
   Dec 13 11:57:24   deploy install   org.freedesktop.Platform.Locale        23.08       system          flathub
[a lista está truncada]

Para renovar e reparar o sistema de referências a repositórios do flatpak, usamos . A remoção de extensões e runtimes não usados por qualquer um dos aplicativos instalados, usamos uninstall --unused.

$ sudo flatpak repair 
➡ Working on the system installation at /var/lib/flatpak
  [175/175] Verifying flathub:runtime/com.bitwarden.desktop.Locale/x86_64/stable… # os aplicativos e runtimes são verificados
  Checking remotes...
  
# para eliminar 
$ flatpak uninstall --unused
➡ Nothing unused to uninstall

A reparação de uma instalação do flatpak faz uma verificação geral das referências disponíveis localmente, removendo aquelas que não correspondem a pacotes instalados. Ela também remove as referências a objetos inválidos e aqueles que não estão referenciados por nenhum aplicativo. Finalmente ela enumera as referências instaladas e reinstala aquelas que não estão completas.

Informações sobre pacotes instalados podem ser vistas com:

$ flatpak info com.jeffser.Alpaca
➡ Alpaca - Chat with local AI models
          ID: com.jeffser.Alpaca
         Ref: app/com.jeffser.Alpaca/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 2.9.0
     License: GPL-3.0-or-later
  [saída truncada]

Executando e pesquisando

flatpak run <aplicativo> executa (roda) o <aplicativo>.
Por exemplo, vimos no output de flatpak list que o nome identificador (id) do navegador Brave é com.brave.Browser. Portanto podemos rodar o aplicativo usando o comando:

# para executar o aplicativo do Brave    
$ flatpak run com.brave.Browser
➡ Gtk-Message: 19:18:19.612: Failed to load module "canberra-gtk-module"
# possíveis mensagens de erro, como a mostrada acima, são listadas no console

# uma lista de aplicativos em execução é exibida com ps
$ flatpak ps
➡ Instance   PID   Application       Runtime
  3817365666 3283  org.geany.Geany   org.freedesktop.Sdk
  846534418  16554 com.brave.Browser org.freedesktop.Platform
  1876930084 16599 com.brave.Browser org.freedesktop.Platform

# para fechar um aplicativo usamos kill 
$ flatpak kill com.brave.Browser
# o Brave (duas instâncias) é fechado

Utilitários GUI

Algumas das funções de gerenciamento de pacotes podem ser executadas através de aplicativos com interface gráfica. Atualmente no repositório Flathub encontramos, por exemplo:

Easy Flatpak: uma loja de aplicativos flatpak, que auxilia na instalação de aplicativos de uma forma amigável, apenas clicando nos botões. Em alguns casos existem receitas para aperfeiçoar algumas instalações, como no caso do Steam, que permite ao usuário escolher o diretório de armazenamento dos jogos.

Flatseal: um utilitário gráfico que permite a visualização e edição das permissões de aplicativos flatpak.

Flatsweep: permite a remoção de arquivos e dependência eventualmente deixados na remoção de um pacote.

Warehouse: fornece uma IU simples para controlar opções complexas do flatpak, sem recorrer à linha de comando. Com ele é possível:

gerenciar Flatpaks instalados e visualizare propriedades dos pacotes,
alterar versões de um Flatpak e reverter atualizações indesejadas,
fixar os runtimes e mascarar Flatpaks (para evitar atualizações),
filtrar pacotes e classificar dados para tornar as buscas mais eficientes,
consultar dados atuais do usuário do aplicativo, limpando dados desnecessários,
adicionas repositórios do Flatpak,
fazer instantâneos (snapshots) de dados do usuário e aplicativos para backup,
instalar pacotes de qualquer repositório remoto ou pacotes baixados.

Resumo dos comandos

Uso: flatpak [OPTION…] COMMAND

Opção de ajuda: flatpak -h ou flatpak --help exibe a lista de comandos do flatpak.

Comandos internos (Built in): gerencia aplicativos e runtimes^† instalados

`install`	Instala aplicativo ou `runtimes`^†
`update`	Atualiza um aplicativo ou `runtime`^† instalados
`uninstall`	Desinstala um aplicativo ou `runtimes`^†
`mask`	Aplica máscara para excluir atualizações e instalações automáticas
`pin`	Trava um `runtime`^† para impedir a remoção automática
`list`	Lista aplicativos e/ou `runtimes`^† instalados
`info`	Mostra informações sobre aplicativos ou `runtimes`^† instalados
`history`	Lista o histórico
`config`	Configura o flatpak
`repair`	Repara a instalação do flatpak
`create-usb`	Coloca aplicativos ou `runtimes`^† em mídia removível

Busca de aplicativos e runtimes^†

`run`	Executa um aplicativo
`override`	Sobreescreve as permissões de um aplicativo
`make-current`	Especifica qual a versão padrão a ser executada
`enter`	Insire o namespace de um aplicativo em execução
`ps`	Lista os aplicativos em execução
`kill`	Interrompe a execução de um aplicativo

Gerencia o acesso a arquivos:

`documents`	Lista arquivos exportados
`document-export`	Concede a um aplicativo acesso a um arquivo específico
`document-unexport`	Revoga acesso a um arquivo específico
`document-info`	Mostra informações sobre um arquivo específico

Gerencia permissões dinâmicas

`permissions`	Lista permissões
`permission-remove`	Remove item do armazenamento de permissões
`permission-set`	Define permissões
`permission-show`	Mostra permissões do aplicativo
`permission-reset`	Redefine permissões do aplicativo

Gerencia repositórios remotos

`remotes`	Lista todos os repositórios remotos configurados
`remote-add`	Adiciona um novo repositório remoto (por URL)
`remote-modify`	Modifica propriedades de um repo remoto configurado
`remote-delete`	Excluir um repo remoto configurado
`remote-ls`	Lista o conteúdo de um repositórioa configurado
`remote-info`	Exibe informações sobre aplicativo remoto ou `runtime`^†

Construção de aplicativos

`build-init`	Inicializa um diretório para construção
`build`	Executa um comando dentro do diretório de construção
`build-finish`	Conclui um diretório de construção para exportação
`build-export`	Exporta diretório de construção para um repositório
`build-bundle`	Cria um arquivo de pacote usando referência a repositório local
`build-import-bundle`	Importa um arquivo de pacote
`build-sign`	Assina um aplicativo ou `runtime`^†
`build-update-repo`	Atualiza o arquivo de resumo de um repositório
`build-commit-from`	Cria novo commit com base na referência existente
`repo`	Exibe informações sobre um repositório

Opções do aplicativo:

`–version`	Imprime informações sobre a versão e termina
`–default-arch`	Imprime a arquitetura padrão e termina
`–supported-arches`	Imprime as arquiteturas suportadas e termina
`–gl-drivers`	Imprime os drivers gl ativos e termina
`–installations`	Imprime caminhos para instalações do sistema e termina
`–print-updated-env`	Imprime o `runtime`^† atualizado necessário para execução de flatpaks
`–print-system-only`	Inclui apenas a instalação do sistema com `–print-updated-env`
`-v, –verbose`	Mostra informações de depuração, `-vv` para mais detalhes
`–ostree-verbose`	Mostra informações de depuração do `OSTree`

Nota †: No contexto do flatpak, runtime, também chamado de platforma, é o ambiente integrado básico de utilitários que permite a execução de um aplicativo flatpak.

Bibliografia

Okay, Containers, Virtualization and Sandboxes, Meaning.
Asks Leo Difference between a Sandbox and a Virtual Machine.
Flatpak, Flatpak’s documentation.
Phylos.net: DNF4 Gerenciador de Pacotes Linux
Read The Docs: Changes between DNF and DNF5
Read The Docs: DNF5 Documentation
Youtube, Slackjeff: FLATPAK, como funciona?
Youtube, The Linux Experiment: FLATPAK, Explained

DNF5: Gerenciador de Pacotes

Posted on 15/12/202415/12/2024 by Guilherme Silva

Todos os tópicos →

Junto com essas notas as seguintes páginas podem ser consultadas:

DNF4 para DNF5

Já vimos nessas notas o funcionamento do DNF, gerenciador de pacotes de software no linux. Nessa ocasião o comando dnf se referia (era um aliás) para dnf4. O Fedora mudou do DNF4 para o DNF5 devido à necessidade de atualizar e melhorar o gerenciador de pacotes do sistema operacional. O DNF5 foi construído pelo esforço coletivo das equipes do Fedora e do Red Hat, e traz várias vantagens em relação à versão anterior, incluindo melhor desempenho, maior estabilidade, correções de bugs e melhorias na interface do usuário. Além disso, o DNF5 oferece suporte a novas funcionalidades e melhor integração com outros componentes do sistema operacional. O DNF5 está instalado no Fedora desde a versão 38, não sendo o gerenciador de pacotes padrão, por default. No Fedora 41 ele é instalado como padrão, e recebe o álias dnf. A versão anterior está ainda disponível, bastando digitar dnf4 na linha de comando. Uma página da documentação descreve as alterações entre dnf4 para dnf5, em Changes between DNF4 and DNF5.

O que é um gerenciador de pacotes?

Um gerenciador de pacotes é um conjunto de aplicativos usados para automatizar o processo de instalação, atualização, configuração e remoção de programas de computador de uma maneira consistente. Ele manipula pacotes, que são distribuições de software e dados, contendo metadados como o nome do software, descrição de propósito, versão, fornecedor, checksum e uma lista de dependências necessárias. Na instalação, os metadados são armazenados em um banco de dados local. Gerenciadores de pacotes usam esse banco de dados de dependências para evitar incompatibilidades de software e pré-requisitos ausentes. Eles trabalham em conjunto com os repositórios de software, algumas vezes acessados pelas lojas de aplicativos. Diversas distribuições Linus usam DNF (ou YUM), entre elas: RedHat Enterprise Linux, Fedora, CentOS, Oracle Enterprise Linux, SUSE, OpenSUSE, Mageia e Turbolinux.

Nessas notas descreveremos o aplicativo DNF5 sem fazer alusão alusão ao artigo anterior, para que ele possa ser lido independentemente.

Usamos aqui as seguintes convenções:
# linhas de comentários
$ linhas de código (input)
➡ linhas de saída (output)

O que é RPM?

O RPM Package Manager (RPM) é um sistema de gerenciamento de pacotes de código aberto. Os arquivos que ele empacota recebem a extensão .rpm. O gerente RPM foi criado para uso no Red Hat Linux, mas agora é usado em muitas distribuições Linux, como PCLinuxOS, Fedora Linux, AlmaLinux, CentOS, openSUSE, OpenMandriva e Oracle Linux.

Um pacote RPM pode conter um número variado de arquivos. A maioria deles são “RPMs binários” (ou BRPMs), que contém a versão já compilada de algum software. Também existem “RPMs de origem” (ou SRPMs) que trazem o código-fonte usado para construir um pacote binário. Nesse caso eles têm uma tag no cabeçalho do arquivo que os marca como SRPM e faz com que esses arquivos sejam extraídos para /usr/src na instalação.

Repositórios: RPMs são frequentemente coletados em um ou mais repositórios na internet, chamados repositórios. Alguns sites replicam esses repositórios, nos espelhos locais (ou mirrors). Aplicativos destinados a faciltar o uso desses arquivos, gerenciando instalações, dependências e conflitos são os front ends. Alguns exemplos são: YUM (a base para o dnf); DNF; up2date; Zypper, urpmi, apt-rpm, uma adaptação para usar pacotes rpm no Debian, entre outros.

Banco de dados de instalação local: o gerenciador de pacotes usa uma banco de dados (rpmdb), armazenado em /var/lib/rpm. Diversos gerenciadores podem ser usados, como o SQLite ou Berkeley DB, contendo todas as meta informações dos pacotes instalados. É possível identificar qual o gerenciador está sendo usado com o comando rpm --showrc. Esse banco de dados indexa a informção para acelerar as consultas, e mantém o controle de todos os arquivos alterados e criados pelo usuário, permitindo a reversão das alterações e remoção de pacotes. Em caso de corrupção desse banco de dados de índice, eles podem ser recriados com o comando rpm --rebuilddb.

# para descobrir o dbms usado pelo rpm
$ rpm --showrc

# para restaurar banco de dados corrompido
$ rpm --rebuilddb

O que é DNF5?

O DNF5 é um gerenciador de pacotes que automatiza o processo de instalação, atualização, configuração e remoção de programas de computador de forma consistente. Ele suporta pacotes RPM, módulos modulemd e grupos e ambientes comps. libdnf é a biblioteca de gerenciamento de pacotes, escrita originalmente para suportar o gerenciador de pacotes DNF, mas gradualmente cresceu e se tornou uma biblioteca versátil. Agora é possível usar libdnf para construir ferramentas personalizadas que carregam repositórios, resolvem dependências, consultam e instalam pacotes. O DNF5 também é alimentado pela biblioteca libsolv, que fornece uma interface de programação fácil de usar.

O DNF5 você pode trabalhar com os seguintes artefatos:

Repositórios e pacotes RPM: descritos acima.
Módulos modulemd: modulemd é um arquivo que define quais pacotes são construídos para cada versão do sistema operacional. Ele inclui um resumo e uma descrição, uma lista de pacotes RPM de origem, informações sobre a ordem em que os aplicativos são instalados, junto com macros e informações de uso, ou seja, perfis de instalação e licenças.
Ambientes e grupos comps, Metadados de composição da distribuição (Distribution Compose Metadata): Objetos comps reune informações sobre todos os repositórios disponíveis.
Avisos (updateinfo, erros): Avisos são mensagens informativas que não impedem a conclusão do comando DNF mas indicam problemas potenciais e sugerem alternativas. Updateinfo é um metadado com informações sobre atualizações disponíveis para pacotes. Quando o DNF encontra updateinfo, ele pode exibir informações sobre atualizações disponíveis, incluindo o nome do pacote, versão e repositório. Updateinfo não é um erro, mas sim uma notificação sobre atualizações disponíveis. Erros são mensagens críticas que impedem a conclusão do comando DNF. Eles podem informar da ausência de dependências, erros no repositório, etc.

Instalação

Para instalar o gerenciador de pacotes DNF5, use um dos seguintes comandos, dependendo da sua versão do Fedora. Verifique antes se ele já não está instalado.

# no Fedora 37 ou outro sistema sem a instalação do repositório
$ sudo dnf copr enable rpmsoftwaremanagement/dnf-nightly 
# instalando 
$ sudo dnf install dnf5

# no Fedora 38+ o repositório já está incluído
$ sudo dnf install dnf5
	
# verifique qual versão instalada, e em que diretório.
$ which dnf5
➡ /usr/bin/dnf5
 
# ou 
$ dnf5 --version
➡ dnf5 version 5.2.7.0
  dnf5 plugin API version 2.0
  libdnf5 version 5.2.7.0
  libdnf5 plugin API version 2.0
 [truncado]

Os seguintes comandos são de uso frequente com o dnf (usado como álias para o dnf5):

Comandos:

Comando, aliás	Descrição
`$ dnf upgrade <pacote>`	Atualiza o sistema e pacotes para a versão mais recente.
`$ dnf search <pacote>`	Pesquisa pacotes disponíveis no repositório do sistema.
`$ dnf install <pacote>`	Instala um nova pacote especificado pelo nome.
`$ dnf remove <pacote>`	Remove pacotes instalados especificaods pelo nome.
`$ dnf distro-sync <pacote>`	Sincronize os pacotes instalados com as versões mais recente disponíveis nos repositórios para a versão atual do Fedora.
`$ dnf repoquery <pacote>`	Pesquisa a informação sobre o pacote especificado nos repositórios DNF.
`$ dnf list <pacote>`	Exibe informações sobre pacotes que se ajustem à especificação.
`$ dnf info <pacote>`	Coleta informação detalhada sobre o pacote especificado.
`$ dnf makecache`	Refaz e atualiza o cache de metadata do gerente de pacotes DNF.
`$ dnf repolist`	Exibe a lista de repositórios junto com informações sobre o número de pacotes disponíveis em cada repositório.
`$ dnf repoinfo`	Exibe informação sobre os repositórios configurados no sistema.

As páginas do manual do aplicativo podem ser visualizados com man dnf, para ajuda geral, ou man dnf list para a ajuda sobre o parâmetro específico list ou outro qualquer.

Exemplos de uso do dnf

Alguns exemplos podem ajudar a compreender o uso do dnf. Observe que algumas operações exigem o uso do sudo.
O comando sudo (Super User DO) é usado como um prefixo para comandos que só podem ser executados por superusuários, aqueles que têm permissão. Isso faz com que o comando após o sudo seja executado com privilégios elevados. Vários usuários podem ter acesso ao sudo, desde que estejam declarados como administradores no arquivo sudoers em /etc/sudoers. Por padrão, esses usuários executam funções administrativas usando as suas próprias senhas.

upgrade, search, install, remove

No exemplo abaixo lidamos com a pesquisa, instalação e remoção do aplicativo featherpad, um editor de texto puro usando Qt.

Exemplos de uso:

# fazer a atualização do pacote featherpad
$ sudo dnf upgrade featherpad
➡ Updating and loading repositories:
  Repositories loaded.

# pesquisar pelo pacote nos repositórios cadastrados 
$ dnf search featherpad
➡ Updating and loading repositories:
  Repositories loaded.
  Matched fields: name (exact)
  featherpad.x86_64: Lightweight Qt Plain-Text Editor

# instalar a pacote, que deve estar nos repositórios cadastrados 
$ sudo dnf install featherpad
➡ Updating and loading repositories:
  Repositories loaded.
  Package                   Arch           Version         Repository         Size
  Installing:
featherpad              x86_64         1.5.1-1.fc41    fedora             3.4 MiB

  Transaction Summary:
   Installing:         1 package

  Total size of inbound packages is 893 KiB. Need to download 893 KiB.
  After this operation, 3 MiB extra will be used (install 3 MiB, remove 0 B).
  Is this ok [y/N]: y
# featherpad-0:1.5.1-1.fc41.x86_64 é instalado e pode ser usado
$ featherpad
                                                                                                                                  
# desinstalar o aplicativo featherpad
$ sudo dnf remove featherpad
➡ Package            Arch          Version         Repository            Size
  Removing:
   featherpad      x86_64           1.5.1-1.fc41   fedora                  3.4 MiB
  Transaction Summary:
Removing:  1 package
  Is this ok [y/N]: y
# o featherpad é removido do sistema

# para evitar que a execução seja interrompida por perguntas use
$ sudo dnf install featherpad -y
$ sudo dnf remove featherpad -y

Os comandos de instalação e remoção perguntam ao usuário: Is this ok [y/N]: , sendo que a resposta “Não” é o default. Para responder Yes para todas as perguntas use a chave -y (ou -n para responder No).

makecache, repolist, repoinfo

Também podemos gerenciar, inserindo ou removendo os repositórios cadastrados de acordo com as necessidades.

# para listar os repositórios cadastrados
$ dnf makecache
➡ Updating and loading repositories:
  Repositories loaded.
  Metadata cache created.
  
# para listar os repositórios cadastrados
$ dnf repolist
➡ repo id                                                            repo name
  copr:copr.fedorainfracloud.org:ryanabx:cosmic-epoch                 Copr repo for cosmic-epoch owned by ryanabx
  copr:copr.fedorainfracloud.org:wiiznokes:cosmic-applets-unofficial  Copr repo for cosmic-applets-unofficial owned by wiiznokes
  fedora                                                              Fedora 41 - x86_64
  fedora-cisco-openh264                                               Fedora 41 openh264 (From Cisco) - x86_64
  rpmfusion-free                                                      RPM Fusion for Fedora 41 - Free
  rpmfusion-free-updates                                              RPM Fusion for Fedora 41 - Free - Updates
  rpmfusion-nonfree                                                   RPM Fusion for Fedora 41 - Nonfree
  rpmfusion-nonfree-updates                                           RPM Fusion for Fedora 41 - Nonfree - Updates
  updates                                                             Fedora 41 - x86_64 - Updates

# para listar as propriedades dos repositórios
$ dnf repoinfo
➡ Updating and loading repositories:
  Repositories loaded.
  Repo ID             : copr:copr.fedorainfracloud.org:ryanabx:cosmic-epoch
  Name                : Copr repo for cosmic-epoch owned by ryanabx
  Status              : enabled
  Priority            : 99
  Cost                : 1000
  Type                : available
  Metadata expire     : 172800 seconds (last: 2024-11-15 14:08:04)
  Skip if unavailable : true
  Config file         : /etc/yum.repos.d/_copr:copr.fedorainfracloud.org:ryanabx:cosmic-epoch.repo
  URLs                :
Base URL          : https://download.copr.fedorainfracloud.org/results/ryanabx/cosmic-epoch/fedora-41-x86_64/
  PGP                 :
Keys              : https://download.copr.fedorainfracloud.org/results/ryanabx/cosmic-epoch/pubkey.gpg
Verify repodata   : false
Verify packages   : true
  Repodata info       :
   Available packages : 626
Total packages    : 626
Size              : 22.9 GiB
Revision          : 1731404232
Updated           : 2024-11-12 09:37:12
# [truncado] segue as descrições dos demais repositórios registardos no computador

O comando dnf makecache é usado para baixar metadados para os repositórios habilitados, atualizando os dados locais. Ele tenta evitar o download de novos dados sempre que possível, por exemplo, quando os dados locais ainda não expiraram ou quando o carimbo de data/hora não foram alterados.

repolist é um aliás para repo list (ou seja, list é um parâmetro do comando repo), usado para listar os repositórios cadastrados. Se nenhum repositório estiver configurado ele não apresenta nenhum retorno. Da mesma forma repoinfo é um aliás para repo info, listando repositórios e suas propriedades.

Glossário

Especificação de padrões

Globs: globs são padrões que especificam um comjunto de nomes de arquivos usando caracteres “curingas” ou wildcard. Os padrões aceitos pelo dnf são os mesmos usados pela shell. Os seguintes padrões podem ser usados.

Definições:

`*`	casa com qualquer número de caracteres, ou vazio.
`?`	casa com um caracter único.
`[xyz]`	casa com x, y ou z; qualquer um dos caracteres entre colchetes.
`[a-z]`	casa qualquer um dos caracteres entre a até z, inclusive.
`[!a-z] ou [^a-z]`	não casa com nenhum dos caracteres na faixa de a até z.
`{ }`	colchetes não são suportados.

Exemplos:

`*.txt`	casa com qualquer nome de arquivo que termina com .txt, como “texto.txt”, “aa.txt” ou “.txt”.
`su*.css`	casa com “su.css”, “superman.css” ou “sucata.css”.
`?asa.toml`	casa com qualquer nome de arquivo como “casa.toml”, “rasa.toml” ou “sasa.toml”.
`??uga.pdf`	casa com “aluga.pdf”, “_ruga.pdf” mas não casa com “beluga.pdf”.
`[a-m]luga.hlmt`	casa com “aluga.hlmt”, “gluga.hlmt”, “kluga.hlmt”, mas não com “pluga.hlmt”.
`[!1-5]fix.jpg`	não casa com “3fix.jpg” nem “5fix.jpg”, mas casa com “7fix.jpg”.
`[^1-5]fix.jpg`	o mesmo que acima.

Padrão NEVRA

Pacotes podem ser identificados exclusivamente pela string NEVRA, que consiste de 5 partes de informação:
Name | Epoch | Version | Release | Architecture

São eles: name do pacote (pode conter hifens), Epoch, um número, timestamp, nem sempre incluído, Version uma string, alfanumérica,Release da versão, Architecture, string definindo arquitetura do alvo.

Packages (Pacotes)

Muitos comandos usam o parâmetro <package-spec> para selecionar pacotes. Esse argumento é comparado com NEVRAs de pacotes, provides e file provides. Quando <package-spec> é um nome de pacote ou um provide, o usuário pode fornecer regras adicionais de restrição para corresponder aos argumentos. Comparações de versão podem usar os operadores lógicos =, >, <, >=, <= como, por exemplo, <package-spec>>= <version>, onde o argumento <version> está no formato [EPOCH:]VERSION[-RELEASE] conforme especificado acima.

<package-file-spec> é similar a <package-spec>, exceto que provides matching não é executado. Portanto, <package-file-spec> é correspondido somente com NEVRAs e file provides. <package-name-spec> é correspondido somente com NEVRAs.

Bibliografia

Phylos.net: DNF5: Resumo dos comandos
Phylos.net: DNF5: Descrição dos Comandos
Github: DNF5
Phylos.net: DNF4 Gerenciador de Pacotes Linux
Read The Docs: Changes between DNF and DNF5
Read The Docs: DNF5 Documentation

DNF5, Descrição dos Comandos

Posted on 28/11/202415/12/2024 by Guilherme Silva

Todos os tópicos →

Junto com essas notas as seguintes páginas podem ser consultadas:

Descrição dos comandos do DNF5

A descrição dos comandos listada abaixo é uma versão um pouco resumida dos documentos Read the Docs. Em todos os casos, nessa página, o comando dnfé um aliás para dnf5.

Comando advisory

Uso: dnf5 advisory [options] [<advisory-spec>...

advisory permite vários tipos de consultas para obter recomendações e advertências sobre pacotes. Argumentos opcionais podem ser passados em <advisory-spec> para filtrar recomendações com nomes específicos.

Subcomandos:

`list`	Lista recomendações disponíveis.
`info`	Imprime detalhes sobre recomendações.
`summary`	Imprime um resumo das recomendações.

Opções:

`–all`	Mostra recomendações contendo qualquer versão dos pacotes instalados.
`–available`	Mostra recomendações contendo versões mais recentes dos pacotes instalados. (Default).
`–installed`	Mostra recomendações contendo versões iguais e mais antigas dos pacotes instalados.
`–updates`	Mostra recomendações de versões mais recentes dos pacotes instalados, se existir versão mais recente disponível.
`–contains-pkgs=NOME_DO_PACOTE,…`	Mostra apenas recomendações contendo pacotes com nomes especificados. Esta é uma opção de lista. Somente pacotes instalados são correspondidos. Podem ser usados globs^†.
`–security`	Considera somente o conteúdo contido em avisos de segurança.
`–bugfix`	Considera somente o conteúdo contido em avisos de correção de bugs.
`–enhancement`	Considera somente o conteúdo contido em avisos de aprimoramento.
`–newpackage`	Considera somente o conteúdo contido em avisos de newpackage.
`–advisory-severities=ADVISORY_SEVERITY,…`	Considera somente o conteúdo contido em avisos com gravidade especificada. Esta é uma opção de lista. Os valores aceitos são: `critical, important, moderate, low, none`.
`–bzs=BUGZILLA_ID,…`	Considera somente o conteúdo contido em avisos que corrigem um tíquete de ID do Bugzilla fornecido. Esta é uma opção de lista. Os valores esperados são IDs numéricos, por exemplo. `123123`.
`–cves=CVE_ID,…`	Considera apenas o conteúdo contido em avisos que corrigem um tíquete de ID CVE (Common Vulnerabilities and Exposures) fornecido. Esta é uma opção de lista. Os valores esperados são IDs de string no formato CVE, por exemplo, `CVE-2201-0123`.
`–with-bz`	Mostra apenas avisos que fazem referência a um tíquete do Bugzilla.
`–with-cve`	Mostra apenas avisos que fazem referência a um tíquete CVE.

Exemplos:

# mostra informações e avisos sobre o nome fornecido.
$ dnf advisory FEDORA-2022-07aa56297a

# mostra resumo dos avisos sobre pacotes kernel ou kernel-core com referência a tíquetea do Bugzilla.
$ dnf advisory summary --contains-pkgs=kernel,kernel-core --with-bz

# mostra lista de avisos de segurança ou avisos com gravidade importante
$ dnf advisory list --security --advisory-severities=important

Comando autoremove

Uso: dnf autoremove

autoremove é usado para remover do sistema pacotes desnecessários. Esses pacotes foram provavelmente instalados como dependências para algum aplicativo mais tarde desinstalado, e não são mais exigidos por nenhum aplicativo.

Nota: Pacotes somente de instalação (por exemplo, kernels) nunca são removidos automaticamente por este comando, mesmo que tenham sido instalados como dependências.

A opção –offline armazena a transação para ser executada offline. Essas transações são executadas quando o sistema é inicializado em um ambiente mínimo, o que pode ser mais seguro do que a execução em um sistema inicializado normalmente, já que a transação tem menos probabilidade de interferir em processos sendo executados.
Opção:

–offline

Armazena a transação para ser executada offline.Veja opção offline

Exemplos de uso:

$ sudo dnf autoremove
[sudo] senha para guilherme: 
 Pacote                   Arch        Versão              Repositório       Tamanho
 perl-Mozilla-CA          noarch      20240730-1.fc41     anaconda          9.8 KiB

Is this ok [y/N]: y
Executando transações
[1/2] Preparar transação                                         100% |   2.0   B/s |   1.0   B |  00m00s
[2/2] Removendo perl-Mozilla-CA-0:20240730-1.fc41.noarch         100% |  13.0   B/s |   6.0   B |  00m00s

# para postergar a execução para ambiente mínimo
$ sudo dnf autoremove --offline
➡ Nada a fazer!

Comando check

Uso: dnf check [options]

Verifica o banco de dados packagedb local e responde com informações sobre problemas encontrados. Os testes a serem executados podem ser selecionados com as opções:
Opções:

`–dependencies`	exibe dependências faltantes e conflitos.
`–duplicates`	exibe pacotes duplicados.
`–obsoleted`	exibe pacotes obsoletos.

$ dnf check
$ dnf check --dependencies
$ dnf check --duplicates
$ dnf check --obsoleted
# nenhuma mesagem 'exibido porque o sistema está livre de problemas

Comando check-upgrade

Uso: dnf check-upgrade [options] [<package-spec>...]

Faz uma verificação não interativa para atualizações disponíveis do pacote específico. Se nenhum <package-spec> for especificado o comando verifica por atualizações de todos os pacotes do sistema. Termina exibe no terminal o código 0 se não existirem atualizações; e o código 100, junto com lista dos pacotes, se existirem.
Opções: As seguintes opções podem se usadas:

–changelogs	Imprime os changelogs do pacote,
–advisories=ADVISORY_NAME,…	Considera apenas o conteúdo contido em avisos com nome especificado. Esta é uma lista de opções. Os valores esperados são IDs de avisos, por exemplo, FEDORA-2201-123.
–advisory-severities=ADVISORY_SEVERITY,…	Considera apenas o conteúdo contido em avisos com gravidade especificada. Esta é uma lista de opções. Os valores aceitos são:`critical, important, moderate, low, none`.
–bzs=BUGZILLA_ID,…	Considera apenas o conteúdo contido em avisos que corrigem um tíquete com um ID do Bugzilla. Esta é uma lista de opções. Valores esperados são IDs numéricos, por exemplo, 123123.
–cves=CVE_ID,…	Considera apenas o conteúdo contido em avisos que corrigem um tíquete CVE (Common Vulnerabilities and Exposures) com ID fornecido. Esta é uma lista de opções. Os valores esperados são IDs de string no formato CVE, por exemplo, CVE-2201-0123.
–security	Considera apenas o conteúdo contido em avisos de segurança.
–bugfix	Considera apenas o conteúdo contido em avisos de correção de bugs.
–enhancement	Considera apenas o conteúdo contido em avisos de aprimoramento.
–newpackage	Considera apenas o conteúdo contido em avisos de novo pacote.
–minimal	Relata as versões mais baixas de pacotes que corrigem avisos do tipo bugfix, enhancement, security ou newpackage. Se uma opção que limite avisos seja usada, o relato inclui as versões mais antigas de pacotes que corrigem avisos correspondentes às propriedades de aviso selecionadas

Exemplos:

# imprime lista de pacotes que têm atualizações disponíveis
$ dnf check-upgrade

# imprime logs de alterações para todos os pacotes com atualizações pendentes
$ dnf check-upgrade --changelogs

Comando clean

Uso: dnf clean [options] <cache_types>...

O comando dnf clean é usado para apagar metadata temporariamente matido em repositórios, ou para marcar que um cache está expirado.
Os argumentos em <cache_types> especificam que tipo de dados em cache devem ser limpos.
Argumentos:

`all`	apaga todos os dados temporários de repositórios no sistema,
`packages`	apaga todos os pacotes em cache,
`metadata`	apaga metadados dos repositórios. Isso apaga os arquivos que o DNF5 usa para determinar a disponibilidade remota dos pacotes. Usando essa opção fará com que o DNF baixe todos os metadados em sua próxima execução,
`dbcache`	apaga os arquivos de cache gerados pelo repositório, forçando o DNF a regenerar o cache em sua próxima execução,
`expire-cache`	marca como expirados os metadados do repositório, forçando o DNF a verificar a disponibilidade do cache em sua próxima execução.

Exemplos: Alguns exemplos de uso:

# limpa todos os dados em cache no repositório
$ dnf clean all

# limpa todos os pacotes em cache e metadados no dbcache
$ dnf clean packages dbcache

Comando distro-sync

Uso: dnf distro-sync [options] [<especificação-pacote>...]

O comando dnf distro-sync serve para sincronizar os pacotes instalados com sua versão mais recente disponível em qualquer dos repositórios habilitados. Ele pode ser usado para atualizar, fazer downgrade ou manter pacotes. Argumentos opcionais podem especificar pacotes a serem sincronizados:
Opções:

`–allowerasing`	permitir a remoção de pacotes instalados para resolver quaisquer problemas potenciais de dependência,
`–skip-broken`	Resolver quaisquer problemas de dependência removendo pacotes que estejam causando problemas da transação,
`–skip-unavailable`	Permitir pular pacotes que não são possíveis de sincronizar. Todos os pacotes restantes serão sincronizados,
`–downloadonly`	Baixar o conjunto de pacotes resolvidos sem executar uma transação RPM,
`–offline`	Armazenar a transação a ser executada offline. Veja o comando Offline.

Exemplos de uso:

# sincroniza todo o sistema com a versão mais recente disponível dos pacotes.
$ dnf distro-sync

# Sincroniza o pacote vim com a versão mais recente disponível.
$ dnf distro-sync vim

Comando downgrade

Uso: dnf downgrade [opções] <package-spec>...

downgrade é usado para fazer o downgrade dos pacotes especificados na lista package-spec. É escolhida a versão mais alta, abaixo da versão sendo substituída, quando possível. Se a versão passada no argumento é inferior à versão instalada, o downgrade se dá para esta versaõ especificada.
Opções:

`–allowerasing`	Permite remover pacotes instalados para solucionar problemas de dependência.
`–skip-broken`	Resolve problemas de dependência removendo pacotes que estão causando problemas na transação.
`–skip-unavailable`	Ignora pacotes que não podem passar por rebaixamento. Os demais pacotes são rebaixados.
`–allow-downgrade`	Permite o rebaixamento de dependências na operação solicitada.
`–no-allow-downgrade`	Desabilita o rebaixamento de dependências na operação solicitada.
`–downloadonly`	Baixa os pacotes exigidos sem executar nenhuma transação RPM.
`–offline`	Armazena a transação para ser executada offline. Veja o comando Offline.

Nessa tabela usamos rebaixar para a expressão downgrade, que significa passar para uma versão inferior
Exemplos de uso:

# downgrade do pacote nano para a versão fornecida
$ dnf downgrade nano-0:6.0-2.fc36

# Faça downgrade gcc e glibcpacotes, permitindo a remoção de pacotes instalados quando necessário
$ dnf downgrade gcc glibc --allowerasing

Comando download

Uso: dnf download [options] <package-spec>...

download é usado para baixar pacotes binários de origem definidos nos argumentos package-spec para o diretório de trabalho atual.
Opções:

`–arch`	Limita a pacotes de arquiteturas dadas.
`–resolve`	Resolve dependências de pacotes especificados e baixa os que faltam.
`–alldeps`	Usado junto com `–resolve`, baixa todas as dependências, inclusive as já instaladas.
`–destdir=<path>`	Define o diretório usado para baixar pacotes. O default é o diretório atual.
`–srpm`	Baixa o rpm de origem e habilita todos os repositórios utilizados.
`–url`	Imprime a lista de URLs onde os rpms podem ser baixados, sem fazer nenhum download.
`–urlprotocol`	Usado junto com `–url`, filtra as URLs para os protocolos especificados: `http`, `https`, `ftp`, ou `file`. Pode ser usada várias vezes.
`–allmirrors`	Usado com `–url`, imprime URLs separadas por espaços de todos os mirrors disponíveis para cada pacote.

Exemplos de uso:

# Baixa o pacota kernel-headers usando o formato NEVRA completo. 
$ dnf download kernel-headers-0:5.17.0-300.fc36.i686

# Baixa todos os pacotes com o nome rpm ou rpm-devel.
$ dnf download rpm rpm-devel

# Baixe o pacote maven-compiler-plugin com todas as dependências.
$ dnf download maven-compiler-plugin --resolve --alldeps

# Baixa o pacote maven-compiler-plugin para o diretório /temp/pacotes.
$ dnf download --destdir /temp/pacotes maven-compiler-plugin

# Lista a URL http para baixar o pacote python.
$ dnf download --url --urlprotocol http python

# Baixa o python com a arquitetura x86_64.
$ dnf download python --arch x86_64

# Baixe o rpm do dnf.
$ dnf download dnf --srpm

Comando environment

Uso: dnf environment <subcommand> [options] [...]

environment faz consultas sobre ambientes e grupos relacionados a eles. Argumentos opcionais em environment-spec servem como filtros para selecionar ambientes.
Subcomandos:

`list`	Lista ambientes disponíveis.
`info`	Imprime detalhes sobre os ambientes.

Opções:

`–available`	Mostra ambientes disponíveis mas não instalados.
`–installed`	Mostrar apenas ambientes instalados.

Exemplos de uso:

# Mostrar lista de todos os ambientes.
$ dnf environment list

# Mostrar informações detalhadas sobre o KDEambiente.
$ dnf environment info "KDE Plasma Workspaces"

Comando group

Uso: dnf group {list|info} [options] [...]

Uso: dnf group {install|remove|upgrade} [options] ...

group permite consultas para obter informações sobre grupos, pacotes relacionados a eles e também é usado para instalação de grupos. Para consultar ambientes, use environment.
Nota: dnf4 lista ambientes e grupos com o comando group.

Argumentos opcionais podem ser passados em group-spec para filtrar grupos.
Subcomandos

`list`	Lista todos os grupos correspondentes, instalados e disponíveis. Se nenhum parâmetro for especificado, lista os grupos conhecidos. As opções `–installed` e `–available` restringem a lista solicitada. Se `–hidden` for usado grupos ocultos também são listados.
`info`	Imprime informações detalhadas sobre grupos. Aceita as mesmas opções que `list`.
`install`	Marca grupos especificados e instala seus pacotes. Se a `–with-optional` for especificado, pacotes opcionais são inclídos. Por default todos os pacotes `Mandatory` e `Default` serão instalados se possível. Pacotes condicionais são instalados se atenderem aos requisitos. [Pode ser configurado por dnf-conf(5) , `group_package_types`]. Se o grupo estiver parcialmente instalado, o comando instala os pacotes ausentes. `–no-packages` faz com que nenhum pacote novo seja instalado. Apenas pacotes de grupos instalados são considerados para instalação.
`remove`	Remove os pacotes do sistema e marca o grupo como removido. Ignora pacotes que pertencem a outro grupo instalado e não foram instalados pelo usuário. Se `–no-packages` for usada, nenhum pacote será removido.
`upgrade`	Atualiza a definição do grupo especificado e os pacotes desse grupo. Caso novos pacotes sejam adicionados à definição do grupo após sua instalação, os novos pacotes serão instalados. Se alguns pacotes forem removidos da definição do grupo, eles serão desinstalados, exceto se foram instalados por um motivo diferente (por exemplo, instalados explicitamente por um usuário ou instalados implicitamente como uma dependência).

Opções para list e info:

`–available`	Mostra só grupos disponíveis, não instalados mas são conhecidos pelo DNF5.
`–installed`	Mostra apenas grupos instalados.
`–hidden`	Inclui grupos ocultos.
`–contains-pkgs`	Mostra apenas grupos contendo pacotes com nomes especificados. A opção `list` suporta globs^†.

Opções para install, remove e upgrade:

`–with-optional`	Inclui pacotes opcionais dos grupos, usado com `install`.
`–no-packages`	Opera exclusivamente nos grupos sem manipular nenhum pacote. Usado com `install` e `remove`.
`–allowerasing`	Permite a remoção de pacotes instalados para resolver problemas de dependência. Usado com os comandos `install` e `upgrade`.
`–skip-broken`	Resolve problemas de dependência removendo os pacotes que causam problemas na transação. Usado com `install`.
`–skip-unavailable`	Permite que se ignore pacotes que não podem ser instalados ou atualizados. Usado com `install` e `upgrade`.
`–allow-downgrade`	Permite o downgrade de dependências para resolver a operação solicitada. Usado com `install` e `upgrade`.
`–no-allow-downgrade`	Impede o downgrade de dependências ao resolver a operação solicitada. Usado com os `install` e `upgrade`.
`–downloadonly`	Baixa os pacotes requeridos sem executar uma transação RPM. Usado com `install` e `upgrade`.
`–offline`	Armazena a transação para ser executada offline. Veja o comando Offline.

Exemplos de uso:

# Mostra lista de todos os grupos, incluindo os ocultos
$ dnf group list --hidden

# Mostrar informações detalhadas sobre todos os grupos relacionados a Xfce
$ dnf group info *xfce*

# Instalar o grupo mysql incluindo pacotes opcionais.
$ dnf group install mysql --with-optional

# Atualiza pacotes do grupo mysql em conformidade com a definição atual do grupo.
$ dnf group upgrade mysql

Comando history

Uso: dnf history <subcommand> [options] []

history permite exibe um histórico de transações e oferece opções sobre esses transações, como desfazer ou refazer uma transação. Pressupõe-se que a opção de configuração history_record estava ajustadas quando as transações foram efetuadas.

Subcomandos:

`list`	Lista informações sobre transações registradas no sistema.
`info`	Imprime detalhes sobre transações específicas.
`undo`	Desfaz todas as ações da transação especificada.
`redo`	Repete a transação especificada. Usa automaticamente `–ignore-extras` e `–ignore-installed`. Diferente dos demais comandos do `history`, ele sobreescreve os motivos das transações de pacotes já instalados. Útil para finalizar transações interrompidas.
`rollback`	Desfaz todas as transações realizadas após a transação especificada.
`store`	Armazena a transação em um diretório.

Opções para list e info:

–reverse

Inverte a ordem das transações listadas.

Opções para undo, rollback e redo:

–skip-unavailable

Permite ignorar e pular ações sobre pacotes não são possíveis de executar.

Opções para undo e rollback:

–ignore-extras

Ignaora pacotes extras incluídos na transação como erros. Mesmo assim eles são reportados como avisos.

–ignore-installed

Não trata como erro a incompatibilidades entre pacotes de transações instalados e armazenados.
Mesmo assim são reportados como avisos. O uso dessa opção pode resultar em uma transação vazia.
Para ações de instalação, pule os pacotes já instalados.
Para ações de atualização, ignore grupos ou ambientes que não estão instalados.
Para remover ações, pule pacotes/grupos/ambientes não instalados.

Exemplos de uso:

# Lista todas as transações, da mais recente para mais antigas.
$ dnf history list

# Mostra informações detalhadas sobre a quarta transação.
$ dnf history info 4

# Mostra informações detalhadas sobre a última transação.
$ dnf history info last

# Mostra informações detalhadas sobre a penúltima transação.
$ dnf history info last-1

# Lista transações com ID no intervalo de 4 a 8.
$ dnf history list 4..8

# Desfaz a última transação.
$ dnf history undo last

# Desfaça a quarta transação ignorando pacotes baixados para a transação de reversão
$ dnf history undo 4 --ignore-extras

Comando info

Uso: dnf info [options] [<package-spec>...]

Imprime informações detalhadas sobre os pacotes com base nos parâmetros fornecidos.
Opções:

`–showduplicates`	Mostra todas as versões dos pacotes, e não apenas a mais recente.
`–installed`	Lista só pacotes instalados.
`–available`	Lista apenas pacotes disponíveis.
`–extras`	Lista apenas extras (pacotes instalados no sistema mas não disponíveis em nenhum repositório conhecido).
`–obsoletes`	Lista apenas os pacotes instalados que estão obsoletos em relação a pacotes de qualquer repositório conhecido.
`–recent`	Lista só pacotes adicionados recentemente aos repositórios.
`–upgrades`	Lista apenas as atualizações disponíveis para os pacotes instalados.
`–autoremove`	Lista apenas os pacotes que serão removidos pelo comando autoremove.

Exemplos de uso:

# mostra informações detalhadas sobre pacotes instalados e disponíveis.
$ dnf info

# Imprime informações sobre pacotes recentes cujos nomes começam por gnome.
$ dnf info --recent gnome*

Comando install

Uso: dnf install [options] <package-spec>|@|@...

install é usado para instalar pacotes, grupos ou ambientes. Ao instalar pacotes definidos em package-specargumentos, DNF5garante que os pacotes e suas dependências estejam instalados no sistema. Se os pacotes especificados já estiverem instalados, o DNF5 não verifica suas dependências novamente e simplesmente verifica se os pacotes em si estão presentes.

Ao instalar grupos definidos nos argumentos group-spec, DNF5 garante que os grupos e seus pacotes sejam instalados no sistema. Instala apenas pacotes de grupo que correspondem ao tipo de pacote configurado.
Opções:

`–allowerasing`	Permite a remoção de pacotes instalados para resolver problemas de dependência.
`–skip-broken`	Resolve problemas de dependência removendo os pacotes que estão causando problemas da transação.
`–skip-unavailable`	Permite pular pacotes que não estão disponíveis em repositórios. Todos os pacotes disponíveis são instalados.
`–allow-downgrade`	Habilite o downgrade de dependências ao resolver a operação solicitada.
`–no-allow-downgrade`	Desabilite o downgrade de dependências ao resolver a operação solicitada.
`–downloadonly`	Baixe o conjunto de pacotes resolvido sem executar uma transação RPM.
`–offline`	Armazene a transação a ser executada offline. Veja o comando Offline.
`–advisories=ADVISORY_NAME,…`	Considere apenas o conteúdo contido em avisos com nome especificado. Esta é uma opção de lista. Os valores esperados são IDs de consultoria, por exemplo, `FEDORA-2201-123`.
`–advisory-severities=ADVISORY_SEVERITY,…`	Considere apenas o conteúdo contido em avisos com gravidade especificada. Esta é uma opção de lista. Os valores aceitos são: `critical, important, moderate, low, none`.
`–bzs=BUGZILLA_ID,…`	Considere apenas o conteúdo contido em avisos que corrigem um tíquete de um determinado ID do Bugzilla. Esta é uma opção de lista. Os valores esperados são IDs numéricos, por exemplo, 123123.
`–cves=CVE_ID,…`	Considere apenas o conteúdo contido em avisos que corrigem um tíquete de determinado ID CVE (Common Vulnerabilities and Exposures). Esta é uma opção de lista. Os valores esperados são IDs de string no formato CVE, por exemplo, CVE-2201-0123.
`–security`	Considere apenas o conteúdo contido em avisos de segurança.
`–bugfix`	Considere apenas o conteúdo contido em avisos de correção de bugs.
`–enhancement`	Considere apenas o conteúdo contido em avisos de aprimoramento.
`–newpackage`	Considere apenas o conteúdo contido nos avisos do novo pacote.

Exemplos de uso:

# Instala o pacote tito.
$ dnf install tito

# Instala o arquivo rpm no diretório fornecido.
$ dnf install ~/Downloads/tito-0.6.21-1.fc36.noarch.rpm

# Instala o pacote tito na versão especificada.
# Se o pacote já estiver instalado, ele tentará fazer o downgrade ou o upgrade para a versão dada.
$ dnf install tito-0.6.21-1.fc36

# Instala todos os pacotes que pertencem ao FEDORA-2022-07aa56297 advisory.
$ dnf install --advisory=FEDORA-2022-07aa56297a \*

Comando leaves

O comando leaves serve para todos os pacotes “leafes” (folhas). Pacotes “leafes” são aqueles que estão instalados mas não são dependência de outro pacote instalado. Isso ocorre, por exemplo, quando dois ou mais pacotes marcam um ao outra como dependência, em um ciclo fechado, embora não sejam exigidos por nenhum outro pacote. Esse comando lista pacotes classificados por grupo, sendo o primeiro pacote no grupo marcado pelo caracter “–“.
Opções:
leaves não possui opções, embora considere a configuração install_weak_deps. Se install_weak_deps = false as dependências fracas são ignoradas durante o processamento do conjunto de pacotes leaves.

Por que isso é útil? A lista de pacotes leaves dá uma visão geral e enxuta do que está instalado no sistema. Todos os pacotes que aparecem na lista de leaves podem ser desinstalados sem quebrar nenhuma dependência do sistema.
Exemplo de uso:

# para listar os pacotes "leaves"
$ sudo dnf leaves	
- bluedevil-0:6.2.3-1.fc41.x86_64
- bluez-cups-0:5.79-1.fc41.x86_64
- breeze-gtk-gtk2-0:6.2.3-1.fc41.noarch
- breeze-gtk-gtk3-0:6.2.3-1.fc41.noarch
- breeze-gtk-gtk4-0:6.2.3-1.fc41.noarch
- brltty-0:6.6-19.fc41.x86_64
- cifs-utils-0:7.1-2.fc41.x86_64
- cifs-utils-info-0:7.1-2.fc41.x86_64
# [a lista está truncada]

# para remover "bluedevil-0:6.2.3-1.fc41.x86_64"
$ sudo dnf remove bluedevil-0:6.2.3-1.fc41.x86_64

Nota: Esse comando deve ser usado com cautela para que não sejam removidos pacotes usados pela sistema.

Comando list

Uso: dnf list [options] [<package-spec>...]

O comando list exibe uma lista de pacotes, que pode ser modificada pelos parâmetros fornecidos.
Opções:

`–showduplicates`	Mostra todas as versões dos pacotes, não só a mais recente.
`–installed`	Lista apenas os pacotes instalados.
`–available`	Lista os pacotes disponíveis.
`–extras`	Lista apenas os extras (aqueles instalados no sistema que não estão disponíveis em nenhum repositório conhecido).
`–obsoletes`	Lista os pacotes instalados no sistema tornados obsoletos por pacotes em outro repositório conhecido.
`–recent`	Lista só pacotes adicionados recentemente aos repositórios.
`–upgrades`	Lista apenas as atualizações disponíveis para os pacotes instalados.
`–autoremove`	Lista os pacotes que serão removidos pelo comando autoremove.

Exemplos de uso:

# para listar pacotes instalados e disponíveis.
$ dnf list

# lista todos os pacotes disponíveis, incluindo todas as versões disponíveis.
$ dnf list --available --showduplicates

# lista pacotes instalados e disponíveis com nome iniciado por kde.
$ dnf list kde*

Comando makecache

Uso: dnf makecache [global options]

makecache é usado para criar e baixar metadados para repositórios habilitados. Sempre que possível ele tenta evitar o download de novos dados, por exemplo, quando os metadados locais ainda não expiraram.

dnf makecache atualiza o cache de metadados DNF local. Não há necessidade de executá-lo manualmente porque o DNF atualiza o cache de metadados automaticamente sempre que for executado. Esse comando é normalmente invocado de forma não interativa, por exemplo por um timer systemd, para manter o cache de metadados atualizado.
Exemplo de uso:

# esvazia o diretório /var/cache/libdnf/
$ sudo dnf clean all

# atualiza /var/cache/libdnf/ com infirmações sobre repositórios
$ sudo dnf makecache

# esvazia os repositórios em /var/cache/libdnf/
$ sudo dnf clean metadata

# esvazia caches de repositórios em /var/cache/libdnf/
$ sudo dnf clean all

Comando mark

Uso: dnf mark <subcommand> [global options] [] <package-spec>...

Quando pacotes são instalados com dnf um “motivo” para a instalação fica armazendo nos metadados do banco de dados. mark altera o motivo para essa instalação. Esse motivo fica definido no argumento package-spec.
Subcomandos:

`user`	Marca o pacote como instalado pelo usuário. Útil se um pacote foi instalado como dependência mas o usuário quer marcá-lo para permanecer no sistema quando o comando `remove` for usado junto com a opção `clean_requirements_on_remove=True`.
`dependency`	Marca o pacote como uma dependência. Útil se o usuário precisa de um pacote específico. O pacote permanece instalado no sistema, mas pode ser removido com `remove`, usado junto com a opção `clean_requirements_on_remove=True`. Essa operação deve ser usada no lugar de `remove` se não há certeza de que pacote não é requisito para outro pacote instalado no sistema por outro usuário.
`weak`	Marca o pacote como uma dependência fraca.
`group`	Marca o pacote como instalado pelo grupo definido no argumento `group-id`. Útil se um pacote foi instalado como uma dependência por um usuário, mas espera-se que ele seja protegido e tratado como pertencente a um grupo, pelo comando `group remove`.

Opções:

–skip-unavailable

Permite pular pacotes que não instalados no sistema. Pacotes instalados serão marcados.

Exemplos de uso:

# marca o pacote fuse-devel como instalado pelo usuário
$ dnf mark user fuse-devel

# marca o pacote vim-enhanced como instalado pelo grupo xfce-desktop
$ dnf mark group xfce-desktop vim-enhanced

Comando module

Uso: dnf module <subcommand> [options] [...]

Modularidade é uma forma alternativa de montar, organizar e entregar pacotes. Atualmente, existe apenas suporte básico para gerenciar os módulos, que não recebem mais suporte nas principais distribuições RPM. Mais detalhes em: Modularity e Read The Docs.

Comando offline

Uso: dnf offline <subcommand> [options]

offline é utilizado para gerenciar transações “offline”, que são aquelas executadas quando o sistema é inicializado num ambiente mínimo. Nesse ambiente, rodando um número menor de processos, é mais seguro executar transações pois é menos provável que a transação interfira com os processos em execução.

Transações offline podem ser iniciadas com o “flag” –offline em qualquer operação (install upgrade distro-sync, etc.), ou via dnf system-upgrade download. Depois que uma transação offline é iniciada podemos executar dnf offline reboot para reiniciar o computador e começar a transação. Os dados para transações offline são armazenados no diretório system state, localizado em /usr/lib/sysimage/libdnf/offline.
Subcomandos:

`clean`	Remove transações offline armazenada e exclui arquivos de pacotes em cache.
`log`	Mostra uma lista de inicializações usadas para transações offline, ou mostra logs de transações offline tentadas. Os logs para cada reinicialização podem ser mostrados com a especificação de um dos números na primeira coluna com o argumento `–number`. Números negativos são usados para listar boots em ordem reversa, começando no último. Por exemplo, `log –number=-1` mostra logs da última transação.
`reboot`	Prepara o sistema para executar transações offline e reinicializa para executar a transação. Só pode ser executado após uma transação offline ser iniciada (por exemplo, por `dnf system-upgrade download)`.
`status`	Mostra o status da transação offline atual.
`_execute`	Executa a transação no ambiente offline. Aviso: apenas para uso interno, não devendo ser executado pelo usuário.

Opções:

`–number=<boot number>`	Mostra o log especificado pelo número. Para ver o número do log execute `dnf offline log--number`. Usado com o subcomando `log`.
`–poweroff`	Desliga o sistema após a conclusão da transação, em vez de reiniciar. Se a transação falhar, o sistema será reiniciado em vez de desligar mesmo com esse sinalizador. Usado com o subcomando `reboot`.

Exemplos de uso:

# prepara a instalação do pacote "hello" como uma transação offline.
$ dnf install --offline hello

# mostra o status da transação offline atual.
$ dnf offline status

# reinicia, executa a transação offline e depois desliga o sistema.
$ dnf offline reboot --poweroff

# Lista os "boots" em que uma transação offline foi tentada.
$ dnf offline log

# Visualiza o log da inicialização mais recente em que uma transação offline foi tentada.
$ dnf offline log --number=-1

Comando provides

Uso: dnf provides [global options] <package-spec>...

provides encontra os pacotes que fornecem o <package-spec>. As especificações podem ser combinadas por nome do arquivo e specs.
Exemplos de uso:

# mostra quais pacotes fornecem o comando tito.
$ dnf provides tito

# mostra quais pacotes fornecem o arquivo /usr/bin/tito
$ dnf provides /usr/bin/tito

# retorna o pacote para rpm e informa se nonexistent_package não retorna resultados.
$ dnf provides rpm nonexistent_package

Nota: Quando nenhum pacote é encontrado por provides, o dnf retorna o código 1 e a lista os recursos que não foram encontrados.

Comando reinstall

Uso: dnf reinstall [global options] <package-spec>...

reinstall é usado para reinstalar pacotes definidos em <package-spec>.
Opções:

`–allowerasing`	Permite remover pacotes instalados para resolver problemas de dependência.
`–skip-broken`	Resolva os problemas de dependência removendo pacotes que causam problemas na transação.
`–skip-unavailable`	Ignora pacotes que não podem ser reinstalaos. Os demais serão reinstalados.
`–allow-downgrade`	Permite o downgrade de dependências para resolver a operação solicitada.
`–no-allow-downgrade`	Desativa o downgrade de dependências ao resolver a operação solicitada.
`–downloadonly`	Baixa o conjunto de pacotes resolvidos sem executar uma transação RPM.
`–offline`	Armazena a transação a ser realizada offline.

Exemplos de uso:

# reinstala o pacote tito.
$ dnf reinstall tito

# reinstala o pacote tito usando arquivo rpm local.
# Útil quando o pacote não está disponível em repositórios habilitados.
$ dnf reinstall ~/Downloads/tito-0.6.21-1.fc36.noarch.rpm

Comando remove

Uso: dnf remove [options] <package-file-spec>|@|@...

remove é usado para remover pacotes, grupos ou ambientes do sistema. Para manter as dependências instaladas junto com o pacote a remover, defina clean_requirements_on_remove = False.
Opções:

`–no-autoremove`	Desativa a remoção de dependências não mais usadas.
`–offline`	Armazena a transação a ser realizada offline.

Exemplos de uso:

# remove o pacote tito.
$ dnf remove tito

Comando replay

Uso: dnf replay [options]

replay permite reexecutar uma transação armazenada no diretório . O diretório de transações pode ser criado com a opção –store, disponível em todos os comandos de transação. A reexecução realizará as mesmas operações sobre pacotes da transação original, retornando erro caso existe diferenças com os pacotes instalados ou suas versões.

Para executar a repetição, o diretório de transações deve conter um arquivo no formato JSON (com o nome transaction.json) descrevendo as operações. O diretório também pode conter pacotes, grupos ou ambientes que serão usados na transação reproduzida.
Opções:

`–ignore-extras`	Não considera como erros pacotes extras baixados pela transação. Eles ainda são relatados como avisos.
`–ignore-installed`	Não considera erros as incompatibilidades entre pacotes de transação instalados e armazenados. Eles ainda serão relatados como avisos. Em ações de instalação, ignore pacotes já instalados. Em ações de atualização, ignore grupos ou ambientes ainda não instalados. Em ações de remoção, ignore pacotes/grupos/ambientes não instalados. Essa opção pode levar a transações vazias.
`–skip-broken`	Resolve problemas de dependência removendo pacotes que causam problemas na transação.
`–skip-unavailable`	Ignore pacotes armazenados na transação não disponíveis no sistema de destino, sem gerar mensagem de erro.

Exemplos de uso:

# Reexecuta transação armazenada em ./transaction.
$ dnf replay ./transaction

# Reexecuta transação armazenada em ./transaction ignorando pacotes não disponíveis.
$ dnf replay ./transaction --skip-unavailable

Comando repo

Uso: dnf repo <subcommand> [options] [...]

repo permite diversos tipos de consultas sobre repositórios configurados no sistema.

Subcomandos:

`list`	Lista repositórios disponíveis.
`info`	Mostra informações detalhadas sobre os repositórios.

Opções:

`–all`	Mostra informações sobre todos os repositórios conhecidos.
`–enabled`	Mostra informações apenas sobre repositórios habilitados. (Default).
`–disabled`	Mostra informações apenas sobre repositórios desativados.

Exemplos de uso:

# imprime informações detalhadas sobre todos os repositórios conhecidos.
$ dnf repo info --all

# imprime repositórios desativados relacionados à depuração.
$ dnf repo list --disabled *-debuginfo

# desative persistentemente o repositório usando o plugin config-manger.
$ dnf config-manger setopt repo_id.enabled=0

Comando repoquery

Uso: dnf repoquery [options] [...]

repoquery é usado para consultar pacotes correspondentes a diversos critérios fornecido pelo usuário. Argumentos definidos na lista spec são usados como <package-file-spec>.

Opções:

`–advisories=ADVISORY_NAME,…`	Limita a pacotes em `advisory` com nome especificado. Esta é uma opção de lista. Valores esperados são IDs `advisory`, por exemplo:`FEDORA-2201-123`.
`–advisory-severities=ADVISORY_SEVERITY,…`	Limita a pacotes em `advisory` com gravidade definida. Esta é uma opção de lista. Valores aceitos são:`critical, important, moderate, low, none`.
`–arch=ARCH,…`	Limita a pacotes das arquiteturas especificadas. Esta é uma opção de lista.
`–available`	Consulta pacotes disponíveis. (Default). Se combinado com `–installed` consulta pacotes instalados e disponíveis.
`–bugfix`	Limita a pacotes com avisos de correção de bugs.
`–bzs=BUGZILLA_ID,…`	Limita a pacotes em avisos que corrigem um Bugzilla ID. Esta é uma opção de lista. Os valores esperados são IDs numéricos, por exemplo: `123123`.
`–cves=CVE_ID,…`	Limita a pacotes em avisos que corrijam um ID CVE (Vulnerabilidades e Exposições Comuns). Esta é uma opção de lista. Os valores esperados são IDs de string no formato CVE, por exemplo: `CVE-2201-0123`.
`–disable-modular-filtering`	Inclui pacotes em módulos inativos.
`–duplicates`	Limita a pacotes instalados e duplicados (ou seja, mais versões de pacotes com o mesmo nome e arquitetura). Pacotes `Installonly` são excluídos desse conjunto.
`–enhancement`	Limita a pacotes com avisos de aprimoramento.
`–exactdeps`	Limita a pacotes que requerem <capability> especificados por `–whatrequires` ou `–whatdepends`. Esta opção só pode ser empilhada com `–whatrequires` ou `–whatdepends`.
`–extras`	Limita a pacotes instalados que não presentes em nenhum repositório disponível.
`–file=FILE,…`	Limita a pacotes que possuem os arquivos em `FILE`. Esta é uma opção de lista.
`–installed`	Consulta pacotes instalados. Se combinado com `–available` consulta pacotes instalados e disponíveis.
`–installonly`	Limita a pacotes `installonly` instalados.
`–latest-limit=N`	Limita a N pacotes mais recentes para uma arquitetura. Se `N < 0` usa todos os pacotes.
`–leaves`	Limita a pacotes `leaves` (instalados mas não exigidos por outros pacotes instalados).
`–newpackage`	Limita a pacotes em avisos de `newpackage`.
`–providers-of=PACKAGE_ATTRIBUTE`	Obtem o atributo de pacotes selecionados pelo atributom depois que a filtragem é concluída. Pacotes resultantes são limitados pelas opções `–available –installed –arch`. Tem suporte para: `conflicts, depends, enhances, obsoletes, provides, recommends, requires, requires_pre, suggests, supplements`.
`–recent`	Limita a pacotes alterados recentemente.
`–recursive`	Opção que pode ser usada com `–whatrequires` ou –providers-of=requires. Se usado com `–whatrequires`, estende a saída com pacotes que exigem qualquer coisa fornecida pelos pacotes de saída. Se usado com `–providers-of=requires`: estende a saída com pacotes que fornecem qualquer coisa exigida pelos pacotes de saída. Os pacotes adicionados são limitados pelas opções `–available –installed –arch`.
`–security`	Limita a pacotes em avisos de segurança.
`–srpm`	Utiliza pacotes RPMs de origem correspondentes para a saída após a filtragem. Habilita repositórios de origem.
`–unneeded`	Limita a pacotes instalados mas desnecessários (pacotes que foram instalados como dependências, não mais necessários). Lista pacotes que serão removidos com `autoremove`.
`–upgrades`	Limita a pacotes disponíveis que atualizam alguns pacotes já instalados.
`–userinstalled`	Limita a pacotes que não marcados como dependências ou como dependências fracas. Isso limita os pacotes que foram instalados a pedido do usuário ou indiretamente, como parte de um perfil de módulo ou grupo de composições. Também retorna pacotes com motivo desconhecido. O resultado pode ser influenciado pela opção “exclude” no arquivo de configuração. Para obter a razão exata da instalação, use a opção `–queryformat ‘%{name} %{reason}\n`‘.
`–whatconflicts=CAPABILITY,…`	Limita a pacotes em conflito com qualquer um dos listados em <capabilities>. Esta é uma opção de lista.
`–whatdepends=CAPABILITY,…`	Limita a pacotes que requerem, melhoram, recomendam, sugerem ou complementam qualquer um em <capabilities>. Esta é uma opção de lista.
`–whatenhances=CAPABILITY,…`	Limita a pacotes que melhoram qualquer um dos recursos em <capabilities>. Use `–whatdepends` para listar todos os pacotes dependentes. Esta é uma opção de lista.
`–whatobsoletes=CAPABILITY,…`	Limita a pacotes que tornem obsoletos qualquer um dos <capabilities>. Esta é uma opção de lista.
`–whatprovides=CAPABILITY,…`	Limita a pacotes que fornecem qualquer uma das <capabilities>. Esta é uma opção de lista.
`–whatrecommends=CAPABILITY,…`	Limite a pacotes que recomendam qualquer um dos <capabilities>. Use `–whatdepends` para listar todos os pacotes dependentes. Esta é uma opção de lista.
`–whatrequires=CAPABILITY,…`	Limite a pacotes que requeiram qualquer uma das <capabilities>. Use `–whatdepends` para listar todos os pacotes dependentes. Esta é uma opção de lista.
`–whatsuggests=CAPABILITY,…`	Limita a pacotes que sugiram qualquer uma das <capabilities><>. Use `–whatdepends` para listar todos os pacotes dependentes. Esta é uma opção de lista.
`–whatsupplements=CAPABILITY,…`	Limita a pacotes que complementem qualquer um dos <capabilities>. Use `–whatdepends` para listar todos os pacotes dependentes. Esta é uma opção de lista.

Opções de formatação podem ser usadas para definir quais informações são exibidas sobre cada pacote. Leia mais sobre os comandos de formatação em Read the Docs: Repoquery.

As opções de formatação podem ser usadas para definir quais informações são exibidas sobre cada pacote. Os parâmetros listados na tabela abaixo são mutuamente exclusivos, ou seja, apenas um pode ser especificado em cada consulta. Se nenhuma opção for fornecida, os pacotes selecionados serão exibidos no formato de consulta “%{full_nevra}”.

Na tabela abaixo cada uma das opções funciona como a opção dada na segunda coluna, exceto que as duplicações na saída são removidas e as linhas são ordenadas.

Opções de formatação:

Opção:	Funciona como:
`–conflicts`	`--qf "%{conflicts}"`
`–depends`	`--qf "%{depends}"`
`–enhances`	`--qf "%{enhances}"`
`–files`	`--qf "%{files}"`
`–obsoletes`	`--qf "%{obsoletes}"`
`–provides`	`--qf "%{provides}"`
`–recommends`	`--qf "%{recommends}"`
`–requires`	`--qf "%{requires}"`
`–requires-pre`	`--qf "%{requires_pre}"`
`–sourcerpm`	`--qf "%{sourcerpm}"`
`–suggests`	`--qf "%{suggests}"`
`–supplements`	`--qf "%{supplements}"`
`–location`	`--qf "%{location}"`
`–info`	Mostra informações detalhadas sobre o pacote.
`–changelogs`	Imprime os changelogs de pacotes.
`–querytags`	Exibe tags disponíveis para –queryformat.
`–queryformat=<format>`	Formato de exibição para pacotes. As tags estão descritas na tabela abaixo.

As tags usadas com dnf repoquery --queryformat=<format> estão descritas abaixo. A string <format> pode conter tags (%{<tag>}i) que são substituídos por atributos correspondentes do pacote. Saídas duplicadas são removidas. O default é “%{full_nevra}”.

Tags:

Tag:	Exibe:
`arch`	arquitetura do pacote.
`buildtime`	tempo de compilação do pacote, em Unix time.
`conflicts`	recursos em conflito com o pacote^†.
`debug_name`	nome do pacote debuginfo do pacote
`depends`	as dependências desse pacote. Aprimora, recomenda, sugere ou complementa^†.
`description`	descrição do pacote.
`downloadsize`	tamanho do download do pacote.
`enhances`	recursos de exibição aprimorados pelo pacote^†.
`epoch`	`epoch` (linux data) do pacote.
`evr`	epoch:version-release (versão e lançamento) do pacote. A época 0 é omitida.
`files`	arquivos contidos no pacote^†.
`from_repo`	id do repositório onde está o pacote. Vazio para pacotes não instalados.
`full_nevra`	name-epoch:version-release.arch do pacote. A época 0 está incluída.
`group`	grupo do pacote. Este não é o grupo Comps.
`location`	local do pacote.
`installsize`	tamanho de instalação do pacote.
`installtime`	tempo de instalação do pacote.
`license`	licença do pacote.
`name`	nome do pacote.
`obsoletes`	recursos tornados obsoletos pelo pacote^†.
`packager`	empacotador do pacote.
`prereq_ignoreinst`	requisitos `requires_pre` que podem ser removidos.Vazio para pacotes não instalados^†.
`provides`	recursos fornecidos pelo pacote^†.
`reason`	motivo pelo qual os pacotes foram instalados.
`recommends`	recursos recomendados pelo pacote^†.
`regular_requires`	recursos exigidos pelo pacote sem os requisitos `%pre %post %preun e %postun`^†.
`release`	versão do pacote.
`repoid`	id do repositório que contém o pacote.
`reponame`	nome do repositório que contém o pacote.
`requires`	recursos exigidos pelo pacote (combina `regular_requires e requires_pre`).
`requires_pre`	capacidade exigida pelo pacote (se instalado) para executar seus scripts `%pre %post %preun e %postun`. Apenas requisitos para `%pre e $post`^† para pacote não instalado.
`source_debug_name`	nome do pacote `debuginfo` para o pacote de origem.
`source_name`	nome do RPM de origem do pacote.
`sourcerpm`	fonte RPM do pacote.
`suggests`	recursos sugeridos pelo pacote^†.
`summary`	resumo do pacote.
`supplements`	capacidades suplementadas pelo pacote^†.
`url`	url do pacote.
`vendor`	fornecedor do pacote.
`version`	versão do pacote.

Nota: as tags marcadas com † produzem um output com linhas separadas por quebras de linha.

Exemplos de uso:

# listar pacotes que fornecem o arquivo /etc/koji.conf.
$ dnf repoquery /etc/koji.conf

# listar pacotes que contêm o "http" no nome.
$ dnf repoquery *http*

# listar pacotes instalados incluídos em qualquer advisory de segurança.
$ dnf repoquery --installed --security

Comando search

Uso: dnf search [options] <pattern>...

search é usado para pesquisar pacotes em correspondência com palavras-chave fornecida pelo usuário, em vários metadados. Por padrão, o comando procura todas as chaves solicitadas (usando AND) nos campos Name ou Summary dos metadados do pacote RPM. A correspondência é insensível ao caso (maíuscula/minúsculas) e globs^† são suportados.
Opções:

`–all`	A busca por padrões de pesquisa inclui os campos `Description` e `URL`, nos metadados. Com essa opção, a pesquisa lista os pacotes que correspondem a pelo menos uma das chaves (usando OR).
`–showduplicates`	Mostra todas as versões de pacotes, não apenas as mais recentes.

Exemplos de uso:

# procura a palavra-chave kernel nos campos Name ou Summary dos metadados do pacote.
$ dnf search kernel

# procura pacotes com palavras-chaves rpm e dbus (ambos) nos campos Name ou Summary.
$ dnf search rpm dbus

# procura pacotes com qualquer uma das palavras-chave nos campos Name, Summary, Description ou URL.
$ dnf search --all fedora gnome kde

Comando swap

Uso: dnf swap [options]

swap é usado para remover um pacote e instalar outro em uma única transação.
Opções:

`–allowerasing`	Permite que pacotes instalados sejam removidos para resolver problemas de dependência.
`–offline`	Armazena a transação para execução offline.

Exemplos de uso:

# Remove mlocate e instala plocate.
$ dnf swap mlocate plocate

Comando system-upgrade

Uso: dnf system-upgrade <subcommand> [options]

system-upgrade é usado para atualizar o sistema para uma nova versão. O comando baixa perimeiro os pacotes necessários na sessão ativa. Depois ele emite o subcomando reboot para reiniciar o sistema em ambiente “offline” mínimo para aplicar as atualizações. Essa é uma maneira recomendada para atualizar um sistema para uma nova versão principal. O sistema deve estar atualizado (na versão anterior), o que pode ser obtido com $ dnf --refresh upgrade. system-upgrade compartilha vários subcomandos com offline.
Subcomandos:

`clean`	Idêntico ao subcomando de Offline
`download`	Baixa todos os pacotes necessários para a atualização e verifica se eles podem ser instalados.
`log`	Idêntico ao subcomando de Offline
`reboot`	Idêntico ao subcomando de Offline

Opções:
.

`–releasever=`	Obrigatório, define a versão para atualização. Marca a versão `$releasever` em todos os repositórios habilitados.
`–no-downgrade`	Funciona como `dnf update`, não instaland pacotes da nova versão se forem mais antigos do que os já instalados. É o oposto do comportamento default, que sempre instala pacotes da nova versão, mesmo que mais antigos. Funciona como `dnf update$ dnf distro-sync`.
`–number=`	Idêntico ao subcomando de Offline
`–poweroff`	Idêntico ao subcomando de Offline

Exemplos de uso:

# atualizar sistema e carregar repositórios
$ dnf --refresh upgrade

# atualiza sistema e baixa pacotes da versão 40
$ dnf system-upgrade download --releasever 40

# atualiza e reinicializa sistema
$ dnf system-upgrade reboot

# mostrar logs da última tentativa de atualização
$ dnf system-upgrade log --number=-1

Comando upgrade

Uso: dnf upgrade [options] [<package-spec>|@|@...]

upgrade é usado para atualizar pacotes, grupos ou ambientes para a versão mais recente disponível.

Grupos e ambientes não possuem versões, portanto a atualização basicamente significa uma sincronização com a definição disponível atualmente. A atualização do grupo atualiza todos os pacotes desse grupo, e a atualização do ambiente atualiza todos os grupos contidos nesse ambiente.
Opções:

`–minimal`	Atualiza pacotes para as versões mais baixas disponíveis que corrigem `advsories` do tipo correção de bugs, aprimoramento, segurança ou newpackage. Se uma opção de limitação de avisos for usada, atualiza os pacotes para as versões mais baixas que corrige avisos correspondentes às propriedades selecionadas
`–allowerasing`	Permite remover pacotes instalados para resolver problemas de dependência.
`–skip-unavailable`	Permite ignorar pacotes não possíveis de atualizar. Os demais pacotes serão atualizados.
`–allow-downgrade`	Habilita o downgrade de dependências para resolver a operação solicitada.
`–no-allow-downgrade`	Desativa o downgrade de dependências para resolver a operação solicitada.
`–destdir=`	Define o diretório usado para baixar pacotes. O default é o diretório atual. Automaticamente define a opção `downloadonly`.
`–downloadonly`	Apenas baixa pacotes para transação.
`–offline`	Armazena a transação para execução offline. Veja o comando Offline.
`–advisories=ADVISORY_NAME,…`	Considera apenas o conteúdo contido em avisos com nome especificado. Esta é uma opção de lista. Os valores esperados são IDs consultivos, por exemplo. `FEDORA-2201-123`.
`–advisory-severities=ADVISORY_SEVERITY,…`	Considera apenas o conteúdo contido em avisos com gravidade especificada. Esta é uma opção de lista. Os valores aceitos são: `critical, important, moderate, low, none`.
`–bzs=BUGZILLA_ID,…`	Considera só o conteúdo em avisos que corrigem um ticket de determinado ID do Bugzilla. Esta é uma opção de lista. Os valores esperados são IDs numéricos, por exemplo. `123123`.
`–cves=CVE_ID,…`	Considera só conteúdo em avisos que corrigem um ticket de determinado ID CVE (Vulnerabilidades e Exposições Comuns). Esta é uma opção de lista. Os valores esperados são IDs de string no formato CVE, por exemplo: `CVE-2201-0123`.
`–security`	Considera só o conteúdo nos avisos de segurança.
`–bugfix`	Considera só o conteúdo nos avisos de correção de bugs.
`–enhancement`	Considera só o conteúdo nos avisos de aprimoramento.
`–newpackage`	Considera só o conteúdo nos avisos do `newpackage`.

Exemplos de uso:

# atualiza todos os pacotes instalados para a versão mais recente disponível.
$ dnf upgrade

# atualizar o pacote tito.
$ dnf upgrade tito

Comando versionlock

Uso: dnf versionlock <subcommand> <package-spec>...

versionlock recebe uma lista de nomes e versões para pacotes e exclui todas as demais versões desses pacotes. Dessa forma é possível proteger pacotes, impedindo que sejam atualizados para versões mais recentes. Alternativamente, o comando pode recer uma versão de pacote específica a ser excluída das atualizações, por exemplo, para ignorar uma versão específica de um pacote que tenha problemas conhecidos.

O plugin percorre as entradas do arquivo versionlock, excluindo pacotes cujo nome não corresponde às condições listadas. Isso é idêntico a usar dnf –exclude com o próprio nome do pacote (pois não se pode excluir pacotes instalados). No entanto as versões installed ou versionlocked ainda serão vistas como disponíveis pelo dnd, que ainda poderá reinstalar essas versões.

Nota: o comando versionlock não aplica nenhuma exclusão em operações não transacionais, como repoquery, list ou info.
Subcomandos:

`add`	Adicione um `versionlock` em todos os pacotes disponíveis correspondentes à especificação. Isso significa que apenas pacotes e versões representados em `package-spec` ficam disponíveis para operações de transação.
`exclude`	Adiciona uma exclusão (dentro do `versionlock`) para os pacotes correspondentes à especificação. Pacotes representados por `package-spec` serão excluídos das operações de transação.
`clear`	Remove todas as entradas de `versionlock`.
`delete`	Remove todas as entradas de `versionlock` correspondentes.
`list`	Lista as entradas do `versionlock`.

Exemplos de uso:

# trava a versão do pacote acpi, se estiver instalado, para a versão atual.
# se acpi não estiver instalado, trava a versão do acpi para qualquer uma das versões disponíveis atualmente.
$ dnf versionlock add acpi

# mostra a configuração atual do versionlock.
$ dnf versionlock list

# remove todas as regras para o pacote acpi.
$ dnf versionlock delete acpi

# Exclui a versão iftop-1.2.3-7.fc38.
$ dnf versionlock exclude iftop-1.2.3-7.fc38

Formato de arquivo versionlock: versionlock é um arquivo TOML armazenado em /etc/dnf/versionlock.toml. Ele deve conter uma chave de versão (atualmente a versão suportada é 1.0). Ele também contém uma lista de entradas de bloqueio, em packages. Cada item da lista consiste no nome do pacote e uma lista de condições, que devem ser True para pacotes que correspondem às especificações (usando AND lógico). O conjunto das entradas são combinadas com a operação lógica OR.

Exemplos de arquivos versionlock podem ser vistos em Read the Docs: VersionLock.

Glossário

Especificação de padrões

Definições:

`*`	casa com qualquer número de caracteres, ou vazio.
`?`	casa com um caracter único.
`[xyz]`	casa com x, y ou z; qualquer um dos caracteres entre colchetes.
`[a-z]`	casa qualquer um dos caracteres entre a até z, inclusive.
`[!a-z] ou [^a-z]`	não casa com nenhum dos caracteres na faixa de a até z.
`{ }`	colchetes não são suportados.

Exemplos:

`*.txt`	casa com qualquer nome de arquivo que termina com .txt, como “texto.txt”, “aa.txt” ou “.txt”.
`su*.css`	casa com “su.css”, “superman.css” ou “sucata.css”.
`?asa.toml`	casa com qualquer nome de arquivo como “casa.toml”, “rasa.toml” ou “sasa.toml”.
`??uga.pdf`	casa com “aluga.pdf”, “_ruga.pdf” mas não casa com “beluga.pdf”.
`[a-m]luga.hlmt`	casa com “aluga.hlmt”, “gluga.hlmt”, “kluga.hlmt”, mas não com “pluga.hlmt”.
`[!1-5]fix.jpg`	não casa com “3fix.jpg” nem “5fix.jpg”, mas casa com “7fix.jpg”.
`[^1-5]fix.jpg`	o mesmo que acima.

Padrão NEVRA

Pacotes podem ser identificados exclusivamente pela string NEVRA, que consiste de 5 partes de informação:
Name | Epoch | Version | Release | Architecture

Packages (Pacotes)

Bibliografia

Read the DocsChanges from DNF4 to DNF5
Read the DocsDNF Commands

DNF5, Resumo Geral

Posted on 28/11/202415/12/2024 by Guilherme Silva

Todos os tópicos →

Junto com essas notas as seguintes páginas podem ser consultadas:

Descrição geral do comando DNF5

Uso:
dnf [Opções Globais] <Comando> ...

Nota: usamos aqui dnf como um aliás para dnf5.

Comandos de gerenciamento de software

Comando	Descrição
`install`	Instalar software
`upgrade`	Atualizar software
`remove`	Remover (desinstalar) software
`distro-sync`	Atualizar ou fazer downgrade do software instalado para as últimas versões disponíveis
`downgrade`	Fazer downgrade do software
`reinstall`	Reinstalar software
`debuginfo-install`	Instalar pacotes debuginfo
`swap`	Remover software e instalar outro na mesma transação
`mark`	Alterar o motivo de um pacote instalado
`autoremove`	Remover todos os pacotes instalados como dependências e agora desnecessários
`provides`	Encontre qual pacote fornece o valor fornecido
`replay`	Refazer uma transação anteriormente armazenada em um diretório
`check-upgrade`	Verificar se há atualizações disponíveis para pacotes
`check`	Verifique se há problemas no packagedb

Comandos de consulta

Comando	Descrição
`leaves`	Lista grupos de pacotes instalados não necessários para outros pacotes instalados
`repoquery`	Pesquise por pacotes que correspondam a vários critérios
`search`	Pesquise por software que corresponda a todas as strings especificadas
`list`	Lista pacotes dependendo da relação dos pacotes com o sistema
`info`	Lista pacotes dependendo da relação dos pacotes com o sistema

Subcomandos

Subcomando	Descrição
`group`	Gerencia grupos de comps
`environment`	Gerencia ambientes de comps
`module`	Gerencia módulos
`history`	Gerencia histórico de transações
`repo`	Gerencia repositórios
`advisory`	Gerencia avisos
`versionlock`	Gerencia configuração de versionlock
`system-upgrade`	Prepara o sistema para atualização para uma nova versão
`offline-distrosync`	Armazena uma transação de distro-sync para ser executada offline
`offline-upgrade`	Armazena uma transação de atualização para ser executada offline
`offline`	Gerencia transações offline
`config-manager`	Gerencia configuração

Outros comandos

Comando	Descrição
`clean`	Remove ou expira dados em cache
`download`	Baixa, sem instalar, o software para o diretório atual
`makecache`	Gera o cache de metadados
`builddep`	Instala dependências de compilação para pacote ou arquivo de especificação
`changelog`	Mostra os changelogs do pacote
`copr`	Gera repositórios Copr (complementos fornecidos por usuários/comunidade/terceiros)
`needs-restarting`	Determina se os serviços do sistema ou systemd precisam ser reiniciados
`repoclosure`	Imprime a lista de dependências não resolvidas para repositórios
`build-dep`	Alias de compatibilidade para ‘builddep’

Opções globais:

Comando	Descrição
`-h, –help`	Exibe ajuda
`–config=CONFIG_FILE_PATH`	Localiza o arquivo de configuração
`-q, –quiet`	Junto com comando não interativo mostra só o conteúdo relevante. Suprime notificações sobre o estado atual ou ações do dnf5.
`-C, –cacheonly`	Executa inteiramente com o cache do sistema, mesmo se estiver expirado; não atualiza o cache
`–refresh`	Força a atualização de metadados antes de executar o comando.
`–repofrompath=REPO_ID,REPO_PATH`	cria repositório adicional usando id e caminho
`–setopt=[REPO_ID.]OPTION=VALUE`	define opções arbitrárias de configuração e repositório
`–setvar=VAR_NAME=VALUE`	define variável arbitrária
`-y, –assumeyes`	responde automaticamente sim para todas as perguntas
`–assumeno`	responde automaticamente não para todas as perguntas
`–best`	tenta as melhores versões de pacote disponíveis em transações
`–no-best`	não limita a transação ao melhor candidato
`–no-docs`	Não instala arquivos marcados como documentação (o que inclui páginas de manual e documentos texinfo)
`-x`	pacote,…, –exclude=pacote,… exclui pacotes por nome ou glob
`–enable-repo=REPO_ID,…`	Habilita repositórios adicionais. Opção de lista. Suporta globs, pode ser especificado várias vezes.
`–disable-repo=REPO_ID,…`	Desabilita repositórios. Opção de lista. Suporta globs, pode ser especificado várias vezes.
`–repo=REPO_ID,…`	Habilita apenas repositórios específicos. Opção de lista. Suporta globs, pode ser especificado várias vezes.
`–no-gpgchecks`	desabilita a verificação de assinatura gpg (se a política RPM permitir)
`–no-plugins`	Desabilita todos os plugins libdnf5
`–enable-plugin=PLUGIN_NAME,…`	Habilita plugins libdnf5 por nome. Opção de lista. Suporta globs, pode ser especificado várias vezes.
`–disable-plugin=PLUGIN_NAME,…`	Desabilita plugins libdnf5 por nome. Opção de lista. Suporta globs, pode ser especificado várias vezes.
`–comment=COMMENT`	adiciona um comentário à transação
`–installroot=ABSOLUTE_PATH`	define raiz de instalação
`–use-host-config`	usa configuração, reposdir e vars do sistema host em vez do installroot
`–releasever=RELEASEVER`	substitui o valor de $releasever em arquivos de configuração e repositório
`–show-new-leaves`	Mostra pacotes leaf recém-instalados e pacotes que se tornaram leaves após uma transação.
`–debugsolver`	Despeja resultados detalhados de resolução em arquivos
`–dump-main-config`	Imprime valores de configuração principais no stdout
`–dump-repo-config=REPO_ID,…`	Imprime valores de configuração do repositório no stdout. Opção de lista. Suporta globs
`–dump-variables`	Imprime valores de variáveis no stdout
`–version`	Mostra a versão DNF5 e sai
`–forcearch=FORCEARCH`	Força o uso de uma arquitetura diferente.

Aliases

A primeira coluna é uma lista de aliases de compatibilidade com o dnf4. A segunda coluna mostra aliases de opções:

Alias	Substitui
check-update	check-upgrade
dg	downgrade
dsync	distro-sync
grp	group
if	info
in	install
ls	list
mc	makecache
rei	reinstall
repoinfo	repoinfo
repolist	repolist
rm	remove
rq	repoquery
se	search
up	upgrade
update	upgrade
updateinfo	advisory
upgrade-minimal	upgrade–minimal

Alias	Substitui
-c CONFIG_FILE_PATH	–config
–nobest	–no-best
–nodocs	–no-docs
–enablerepo=REPO_ID,…	–enable-repo
–disablerepo=REPO_ID,…	disable–repo
–repoid=REPO_ID,…	–repo
–nogpgcheck	–no-gpgchecks
–noplugins	–no-plugins
–enableplugin=PLUGIN_NAME,…	–enable-plugin
–disableplugin=PLUGIN_NAME,…	–disable-plugin

Bibliografia

Read the DocsDNF Commands
Read the DocsChanges from DNF4 to DNF5

Flet: CircleAvatar, CupertinoActivityIndicator, Icon

Posted on 24/08/202424/08/2024 by Guilherme Silva

Todos os tópicos →

Controle `CircleAvatar`

O controle CircleAvatar desenha um círculo que pode conter imagens, ícones ou texto. Geralmente é usado para representar o avatar de um usuário. Um texto alternativo pode ser usado para exibição caso a imagem declarada não esteja acessível.

Propriedades e evento de `CircleAvatar`

As seguintes propriedades e evento existem no controle CircleAvatar:

	Descrição
`background_image_src`	recurso de imagem (local ou URL) a ser renderizado no fundo do círculo. Se essa imagem é alterada uma animação será mostrada na troca de imagens. Alterar a imagem de fundo fará com que o avatar anime para a nova imagem. Essa imagem serve como fallback para `foreground_image_src`. Caso as iniciais do usuário devem ser exibidas (ou qualquer outro texto curto), informe a imagem na propriedade `content`.
`bgcolor`	cor de fundo do círculo. Alteração na cor provocará uma animação no avatar para a nova cor.
`color`	cor do texto padrão. Default O padrão é a cor do tema de texto primário se a cor de fundo não for especificada.
`content`	normalmente, um controle de texto. Para apresentar uma imagem em `CircleAvatar` use `background_image_src`.
`foreground_image_src`	A fonte (arquivo de ativo local ou URL) da imagem de primeiro plano no círculo. Normalmente usada como imagem de perfil. Para fallback, use background_image_src.
`max_radius`	O tamanho máximo do avatar, expresso como o raio (metade do diâmetro). Se maxRadius for especificado, o raio também não deve ser especificado. O padrão é “infinito”.
`min_radius`	O tamanho mínimo do avatar, expresso como o raio (metade do diâmetro). Se minRadius for especificado, o raio não deve ser especificado também. O padrão é zero.
`radius`	O tamanho do avatar, expresso como o raio (metade do diâmetro). Se radius for especificado, nem minRadius nem maxRadius podem ser especificados.
`tooltip`	O texto exibido ao passar o mouse sobre o botão.
Evento	Descrição
`on_image_error`	dispara quando ocorre um erro ao carregar imagens em `background_image_src` ou `foreground_image_src`. Os evento tem a propriedade `e.data` que contém uma string com valor “background” ou “foreground”, indicando a origem do erro.

Exemplo de uso do `CircleAvatar`

import flet as ft

def main(page):
    page.bgcolor=ft.colors.WHITE
    foto="https://phylos.net/wp-content/uploads/2017/12/GuilhermeRoundPequeno.png"
    ico=ft.Icon(ft.icons.BEDROOM_BABY)

    a1 = ft.CircleAvatar(foreground_image_src=foto, content=ft.Text("autor"))

    a2 = ft.Stack([a1, ft.CircleAvatar(bgcolor="green", radius=7)], width=40, height=40)

    a3 = ft.CircleAvatar(content=ico, bgcolor="red", color="black")

    a4 = ft.CircleAvatar(content=ico, color="red", bgcolor="black")

    a5 = ft.CircleAvatar(content=ft.Text("@", size=20))

    page.add(ft.Row([a1, a2, a3, a4, a5]))

ft.app(target=main)

Figura 1: resultado do código de CircleAvatar

Os controles CircleAvatar nesse código são:

a1: um avatar comum com imagem de fundo,
a2: um avatar com círculo de status,
a3: um avatar avatar com ícon, e cores customizadas,
a4: um avatar avatar com ícon, e cores customizadas invertidas, e
a5: um avatar com imagem de fundo e texto fallback.

Controle `CupertinoActivityIndicator`

O controle CupertinoActivityIndicator é uma imagem indicadora de atividade no estilo Cupertino (iOS) que pode ou não ser animado. Se animado a imagem gira no sentido horário.

Propriedades de `CupertinoActivityIndicator`

	Descrição
`animating`	booleano, default=True. Se o indicador deve ser animado.
`color`	a cor do indicator
`radius`	raio do indicador de atividade (tamanho).

Exemplo de uso do CupertinoActivityIndicator

import flet as ft

def main(page):
    page.bgcolor=ft.colors.WHITE

    act0=ft.CupertinoActivityIndicator(radius=20, color=ft.colors.GREEN, animating=True)
    act1=ft.CupertinoActivityIndicator(radius=50, color=ft.colors.BLUE, animating=True)
    act2=ft.CupertinoActivityIndicator(radius=30, color=ft.colors.RED)

    page.add(ft.Row([act0, act1, act2]))

ft.app(target=main)

Figura 2: resultado do código de ActivityIndicator

Controle `Icon`

O controle Icon desenha um ícone no estilo Material na página do aplicativo.

Uma página interativa na web pode ser usada para buscar nomes dos ícones desejados, em Flet: Icons Browser.

Propriedades de `Icon`

Propriedade	Descrição
`color`	cor do ícone.
`name`	nome do ícone.
`semantics_label`	nome semântico do ícone. Não é exibido na página mas pode ser acionado em modos de acessibilidade.
`size`	tamanho do ícone. Defaul = 24.
`tooltip`	texto da “dica”, exibido com a passar do mouse (hovering).

Exemplo de uso do Controle Icon

import flet as ft

def main(page: ft.Page):
    page.theme_mode = ft.ThemeMode.LIGHT

    def cor_original():
        ico1.color=ft.colors.PINK
        ico2.color=ft.colors.YELLOW
        ico3.color=ft.colors.GREEN
        ico4.color=ft.colors.BLUE

    def mudar_cor(e):
        if ico1.color==ft.colors.PINK:
            arr_Icons=page.controls[0].controls
            for i in arr_Icons:
                i.color=ft.colors.GREY
        else:
            cor_original()
        page.update()

    def tamanho(e):
        arr_Icons=page.controls[0].controls
        for i in arr_Icons:
            i.size+=5
        page.update()

    ico1=ft.Icon(name=ft.icons.SD_CARD, size=15)
    ico2=ft.Icon(name="sd_card", size=15)
    ico3=ft.Icon(name=ft.icons.ANCHOR, size=30)
    ico4=ft.Icon(name=ft.icons.ELECTRIC_CAR, size=50)
    cor_original()
    bt_cor=ft.ElevatedButton("Mudar Cor", icon="arrow", on_click=mudar_cor, width=150)
    bt_tamanho=ft.ElevatedButton("Tamanho", icon="arrow", on_click=tamanho, width=150)

    page.add(ft.Row([ico1, ico2, ico3, ico4]), ft.Row([bt_cor, bt_tamanho]))

ft.app(target=main)

Figura 3: resultado do código de exemplo de Icon

A figura 3 mostra o resultado do código. A Figura 3-A é o estado inicial do aplicativo. Figura 3-B é o estado após 5 cliques no botão “Tamanho”. O botão “Muda Cor” alterna entre as cores originais e um tom de cinza, para todos os ícones.

Um comentário pode ser útil aqui: como a propriedade de cores dos ícones é usada mais de uma vez, é interessante atribuir essas propriedades em um mesmo bloco de código, o que é feito na função cor_original().

Percorrer todos os ícones para mudar de tamanho ou atribuir a cor cinza foi feita da seguinte forma: foram capturados todos os ícones em um array arr_Icons. Observe que:

page.controls[] é uma lista com 2 linhas,
page.controls[0] é a primeira linha da lista,
page.controls[0].controls é lista de ícones existentes na 1^a linha,
page.controls[0].controls[i] é cada um dos ícones, (i=0,1, 2, 3),
page.controls[0].controls[i].size é o tamanho de cada ícone, e
page.controls[0].controls[i].color é a cor de cada ícone.

Flet, Exemplos: Controles Badge e Canvas

Posted on 21/08/202421/08/2024 by Guilherme Silva

Todos os tópicos →

Exemplos: Badge e Canvas

Exemplo 1: uso do Controle Badge

import flet as ft

def main(page: ft.Page):

    def clicou(e):
        badge.text=str(int(badge.text)+1)
        page.update()

    badge=ft.Badge(
        text="1",
        content=ft.Icon(ft.icons.PHONE, size=40),
        bgcolor="#ff0000",
        text_color="#000000",
    )

    page.navigation_bar = ft.NavigationBar(
        destinations=[ft.NavigationBarDestination(icon_content=badge, label="Soma Um")],
        on_change=clicou
    )
    page.add()

ft.app(main)

A figura 1-A mostra o estado inicial do Badge e 1-B mostra o estado final, após 4 cliques sobre o controle.

Exemplo 2: uso do Canvas.Shapes

O exemplo abaixo mostra casos simples de uso de Color, Circle, Arc, Rect e Line.

import flet as ft
import flet.canvas as cv
import math

def main(page: ft.Page):
    risco = ft.Paint(stroke_width=2, style=ft.PaintingStyle.STROKE)
    pintar = ft.Paint(style=ft.PaintingStyle.FILL)
    cnv = cv.Canvas(
        [
            cv.Color(ft.colors.GREEN_50),                             # A
            cv.Circle(100, 100, 40, risco),                           # B
            cv.Circle(100, 100, 30, risco),                           # C
            cv.Circle(100, 100, 10, pintar),                          # D
            cv.Arc(180, 90, 60, 40, 0, 2*math.pi, paint=risco),       # E
            cv.Arc(180, 80, 60, 20, math.pi, math.pi, paint=risco),   # F
            cv.Rect(165, 60, 90, 80, 15, risco),                      # G
            cv.Line(280, 70, 340, 130, risco),                        # H
            cv.Line(280, 130, 340, 70, risco),                        # I
            cv.Oval(267, 70, 90, 60, risco)                           # J
        ],
    )
    page.add(cnv)

ft.app(main)

Figura 2: representação das curvas marcadas no código

Exemplo 3: uso do Canvas.Path, LineTo, MoveTo

O exemplo abaixo mostra casos simples de uso de Paint, Path, MoveTo, LineTo e Close.

import flet as ft
import flet.canvas as cv
import math

def main(page: ft.Page):
    page.bgcolor=ft.colors.AMBER_100

    def mudar(e):
        caminho1.paint=preenche if caminho1.paint==risco else risco
        caminho2.paint=preenche if caminho2.paint==risco else risco
        caminho1.update()
        caminho2.update()

    risco=ft.Paint(stroke_width=2, style=ft.PaintingStyle.STROKE)
    preenche=ft.Paint(style=ft.PaintingStyle.FILL)
    caminho1=cv.Path(
        [
            cv.Path.MoveTo(25, 25),
            cv.Path.LineTo(105, 25),
            cv.Path.LineTo(25, 105),
            cv.Path.Close()
        ],
        paint=risco
    )
    caminho2=cv.Path(
        [
            cv.Path.MoveTo(125, 125),
            cv.Path.LineTo(125, 45),
            cv.Path.LineTo(45, 125),
            cv.Path.Close()
        ],
        paint=preenche
    )
    page.add(
        ft.ElevatedButton("Mudar estilo de Paint", on_click=mudar),
        cv.Canvas([caminho1, caminho2])
    )
ft.app(main)

Figura 3: Estado inicial e após um clique

Exemplo 3: uso do Canvas.Circle, Rect

O exemplo abaixo mostra casos simples de uso de canvas.Circle, canvas.Rect, canvas.Path, canvas.Path.MoveTo, canvas.QuadraticTo e rotações.

import flet as ft
import flet.canvas as cv

def main(page: ft.Page):
    page.bgcolor=ft.colors.GREEN_200

    gr1=ft.PaintRadialGradient((60, 90), 50, colors=[ft.colors.YELLOW, ft.colors.BLUE])
    grad1=ft.Paint(gradient=gr1, style=ft.PaintingStyle.FILL)
    gr2=ft.PaintRadialGradient((250, 90), 50, colors=[ft.colors.BLACK, ft.colors.RED])
    grad2=ft.Paint(gradient=gr2, style=ft.PaintingStyle.FILL)
    risco=ft.Paint(stroke_width=4, style=ft.PaintingStyle.STROKE)

    fig1=cv.Circle(60, 90, 50, grad1)
    fig2=cv.Path([cv.Path.MoveTo(110, 130), cv.Path.QuadraticTo(160, 1, 210, 130, 1)], paint=risco)
    fig3=cv.Rect(230, 50, 70, 60, 1, grad2)
    fig4=cv.Rect(240, 60, 70, 60, 1, risco)

    page.add(cv.Canvas([fig1,fig2, fig3, fig4]))

ft.app(main)

Exemplo 5: uso do Canvas.Text

O exemplo abaixo mostra casos simples de uso de canvas.Text, estilos e rotações.

import flet as ft, flet.canvas as cv, math

def main(page: ft.Page):
    page.bgcolor=ft.colors.WHITE

    estilo1=ft.TextStyle(weight=ft.FontWeight.BOLD, color=ft.colors.GREEN, size=40)
    estilo2=ft.TextStyle(weight=ft.FontWeight.BOLD, color=ft.colors.RED, size=30)

    texto1=cv.Text(0, 0, "Um texto comum", ft.TextStyle(color=ft.colors.BLUE, size=30))
    texto2=cv.Text(180, 100, "Um texto", estilo1, alignment=ft.alignment.top_center, rotate=math.pi/4)
    texto3=cv.Text(130, 140, "rotacionado", estilo2, alignment=ft.alignment.top_center, rotate=math.pi/4)

    page.add(cv.Canvas([texto1, texto2, texto3]))

ft.app(main)

Exemplo 5: uso do Canvas.Point

O código do próximo exemplo coleta pares de pontos em duas listas, representando seno e cosseno mas as mesmas amplitudes e diferentes comprimentos de onda. As duas listas são representados por meio do canvas.Points.

import flet as ft, flet.canvas as cv, math

def main(page: ft.Page):
    page.bgcolor=ft.colors.WHITE
    risco1=ft.Paint(stroke_width=2, style=ft.PaintingStyle.STROKE, color=ft.colors.BLUE_ACCENT)
    risco2=ft.Paint(stroke_width=2, style=ft.PaintingStyle.STROKE, color=ft.colors.RED)

    seno1=[]
    seno2=[]
    for x in range(500):
        seno1.append((x,50+50*math.sin(.05*x)))
        seno2.append((x,50+50*math.cos(.5*x)))

    cnv=cv.Canvas(
        [
            cv.Points(points=seno1, paint=risco1, point_mode=cv.PointMode.POLYGON),
            cv.Points(points=seno2, paint=risco2, point_mode=cv.PointMode.POLYGON)
        ]
    )
    page.add(cnv)

ft.app(main)

Cosmologia de Buraco Negro

Os Antecedentes

A Hipótese

Universo Holográfico

Observações Recentes

Explicação Alternativa

Conclusões

Bibliografia

Videos

Artigos de Divulgação na Internet

Trabalhos Acadêmicos Relevantes

Livros Recomendados

Conceitos relacionados

Outros Artigos nesse Site

Grupos de Caracteres

Âncoras

Quantificadores

Conjunto e Faixas

Capturando Grupos

Retrovisores

Funções Regex

Flags ou sinalizadores Regex

Bibliografia

Ilusão da Adequação da Informação

Consequências

Narrativas

Exemplos

Metacognição

Realismo Ingênuo

O Estudo

Bibliografia

O que é Comportamento Heurístico

Viéses Cognitivos

Bibliografia

DNF, gerenciado de pacotes

O que é Flatpak

Conceitos básicos

O que é Sandbox

Repositório

Runtimes, bibliotecas empacotadas e portais

Flatpak, instalação e uso

Desinstalação de pacotes:

Atualizando ou rebaixando a versão de pacotes

Gerenciando repositórios

Permissões e Sandboxing

Aplicativos instalados e histórico de operações

Executando e pesquisando

Utilitários GUI

Resumo dos comandos

Bibliografia

DNF5, gerenciador de pacotes

DNF4 para DNF5

O que é um gerenciador de pacotes?

O que é RPM?

O que é DNF5?

Instalação

Exemplos de uso do dnf

upgrade, search, install, remove

makecache, repolist, repoinfo

Glossário

Especificação de padrões

Padrão NEVRA

Packages (Pacotes)

Bibliografia

DNF, gerenciado de pacotes

Descrição dos comandos do DNF5

Comando advisory

Comando autoremove

Comando check

Comando check-upgrade

Comando clean

Comando distro-sync

Comando downgrade

Comando download

Comando environment

Comando group

Comando history

Comando info

Comando install

Comando leaves

Controle `CircleAvatar`

Propriedades e evento de `CircleAvatar`

Exemplo de uso do `CircleAvatar`

Controle `CupertinoActivityIndicator`

Propriedades de `CupertinoActivityIndicator`

Controle `Icon`

Propriedades de `Icon`