1 |
É que em geral, faço emerge -uDav ... o -D faz coisas realmente intrigantes |
2 |
as vezes. O que acontece são coisas do tipo, um novo pacote aparece do nada, |
3 |
provavelmente uma dependencia de outro que ja estava instalado (de repente |
4 |
pro algum erro na hora de fazer o ebuild) e o bendito ficava aparecendo, |
5 |
mesmo pq eu faço emerge do world.... |
6 |
Legal esse paludis. Mas ainda quero que ignore pacotes que peçam downgrade. |
7 |
É que eu uso muito packages.keywords, e as vezes um pacote que estava la |
8 |
passa a depender de outro q não esta la e começa a aparecer pra fazer |
9 |
downgrade... E realmente nao quero ficar checando isso. |
10 |
|
11 |
Valeu pela dica! |
12 |
[]s Magno |
13 |
|
14 |
|
15 |
2008/7/8 Thiago Nunes <thiagonunesrs@×××××.com>: |
16 |
|
17 |
> 2008/7/8 Magno Torres <magnotorres@×××××.com>: |
18 |
> > Eu simplesmente adoraria que existisse uma opção: Atualizar apenas os |
19 |
> > pacotes que tem update, |
20 |
> |
21 |
> Não entendi. Porque pacotes que não tem atualização seriam atualizados? |
22 |
> |
23 |
> > ignorar os pacotes Novos(caso os que estejam em |
24 |
> > update não dependam do mesmo) |
25 |
> |
26 |
> Como assim "ignorar os pacotes Novos"? Mostre um exemplo de pacotes |
27 |
> novos que serão instalados sem que tu tenha os requisitado |
28 |
> explicitamente e que também não sejam dependência da versão mais nova |
29 |
> de outro pacote que está sendo atualizado? |
30 |
> |
31 |
> > e ignorar os marcados para downgrade altém de |
32 |
> > ignorar os pacotes que necessitam de download manual(como ERA o caso do |
33 |
> > java). |
34 |
> |
35 |
> Dá uma olhada no link abaixo e procure por "--dl-downgrade". |
36 |
> http://paludis.pioto.org/clients/paludis.html |
37 |
> |
38 |
> Mas... geralmente se a versão mais nova de uma ebuild saiu do portage |
39 |
> é porque alguém chegou a conclusão de que a versão antiga era melhor. |
40 |
> Porque não acatar essa decisão? |
41 |
> |
42 |
> > Então sempre faço o seguinte procedimento: |
43 |
> > |
44 |
> > Simulo algo como a antiga opção -U (com steroids, claro), com o seguinte |
45 |
> > procedimento: |
46 |
> > Tenho um script emerge.sh: |
47 |
> > |
48 |
> > localhost ~ # cat ~/emerge.sh |
49 |
> > sed '/[^F][UN] *]/!d; s/[^]]*] \([^ ]*\) .*/=\1/' $@ |
50 |
> > |
51 |
> > então rodo o emerge com as opções que quero, geralmente: emerge -uDav |
52 |
> world |
53 |
> > |tee ~emerge |
54 |
> > rodo o script: |
55 |
> > ~/emerge.sh ~/emerge -> Vai me mostrar o que será atualizado. Posso |
56 |
> remover |
57 |
> > algo que não queira colocando |egrep -v opcao1\|opcao2\|etc |
58 |
> > |
59 |
> > Depois finalmente faço o emerge, mas sempre desta forma: |
60 |
> > for i in $(~/emerge.sh ~/emerge) |
61 |
> > do |
62 |
> > echo $i |
63 |
> > emerge -n $i |
64 |
> > done |
65 |
> > |
66 |
> > Com isto, tenho quase a certeza do que eu quis atualizar, ser realmente |
67 |
> > atualizado. Só não vai atualizar se der problema de compilação, mas não |
68 |
> vai |
69 |
> > parar o processo o que me deixava realmente furioso. |
70 |
> |
71 |
> Pois é, isso de parar toda atualização por causa de um pacote que deu |
72 |
> problema realmente não é legal. Mas pega aquele link de cima e procura |
73 |
> por "--continue-on-failure", descobrirás que um dia um programador bom |
74 |
> e indignado o suficiente resolveu solucionar esse problema. |
75 |
> -- |
76 |
> gentoo-user-br@l.g.o mailing list |
77 |
> |
78 |
> |
79 |
|
80 |
|
81 |
-- |
82 |
[]s Magno |
83 |
http://magno.multiply.com |
84 |
-- |
85 |
Linux user: #123834 |
86 |
http://counter.li.org |