Qual era o rumo que gostariam o Gentoo levasse ?

[MetalGod]

Ora mais um topico para flamewars mas o objectivo nao e' esse.
Gostava que com este topico pudessem dizer qual e' o rumo que gostariam que a nossa distro levasse e sugestões para isso.
Sim porque Gentoo "is all about choice".

[Kobal]

2 coisas que queria.

1 - uma opção -0 por exemplo no etc-update , exemplo ao atualizar o baselayout usando o -0 ele faz igual ao -5 mais não move as configurações para outro lugar.

2 - e uma opção no make.conf parecido com a variavel USE, mais ela serveria apenas para remover o que não se usa no portage, exemplo NOPORTAGE -kde -qt -testing , todos os ebuilds do kde , qt e testing seriam removidos do portage. tornado ele menor.

[danvalho]

Sei que a instalação do gentoo está prestes a ganhar uma opção gráfica e explicativa.
Portanto coloco esse comentário para parabenizar e reforçar essa iniciativa.
Pois seria ótimo ter uma instalação facilitada e com explicaçãoes para cada passo realizado.

Falou, pessoal.

[Operador Nabla]

Depois de algum tempo estudando para desenvolver o meu antigo NablaUtils, atual NablaTools, passei a entender um pouco melhor como é o Portage "por dentro". Minha conclusão parcial, possivelmente compartilhada com outros usuários: além de sua implementação muito complicada, o Portage atualmente explora muito pouco o potencial da linguagem Python --- especialmente, a sua orientação a objetos.

Talvez essa "deficiência" não seja sentida pelo usuário final --- se bem que, creio eu, uma exploração melhor dos recursos da plataforma Python poderia deixar o Portage mais ágil --- mas certamente o é por quem costuma desenvolver ferramentas baseadas no Portage. Eu, por exemplo, me vi na necessidade de escrever uma espécie de "camada de abstração sobre o Portage" para usar com as ferramentas do NablaTools só para compensar tais deficiências. Assim, essa "camada de abstração" pode ser vista como parte da minha wish list para futuras versões do Portage, ou seja, uma idéia de como eu gostaria que as coisas fossem organizadas neste.

Outro recurso que poderia ser incluído no Portage é a possibilidade de indicar, num ebuild, que alguns de seus pacotes-dependências sejam compilados com determinadas USE flags ativas ou inativas. Esta necessidade já existe: por exemplo, alguns pacotes multimídia do KDE exigem que o pacote kde-base/kdelibs seja compilado com a USE flag arts ativa. Outros usuários do Gentoo já sugeriram isto em outras salas deste fórum e eu acredito que implementar este recurso seja algo simples --- em breve, eu devo criar um tópico na sala Portage & Programming com uma sugestão para implementar esta funcionalidade.

[Matheus Villela]

Isso que o Nabla comentou realmente é algo que incomoda. Um pacote que sofre desse problema também é o Audacity, se não me engano se o wxgtk está com suporte a unicode ele não instala, o óbvio pra mim e que considero por isso mais intuitivo é ele "sugerir" logo de cara a recompilação do wxgtk sem suporte a unicode caso você queira instalar o audacity e muito interessante seria se ele colocasse por padrão o a USE flag para o wxgtk caso isso ocorra.

Ahh, sei lá, isso é tão específico hehe


Tá tá, algo mais "real": uma ferramenta *gráfica* _OFICIAL_ pra gerenciamento do portage(tipo porthole) e que além disso fosse ferramenta gráfica de configuração do *gentoo* em geral. Algo como o Yast é para o SUSE. Certas vezes é um porre ter que ficar editando coisas na "mão", apesar de que gosto bastante de aplicativos em modo texto e de editar arquivos em modo texto justamente pq a maioria dos programas gráficos são mal-feitos, tal ferramenta gráfica teria que ser feita tendo bastante cuidado com usabilidade porque senão fica como aquelas partes "administrativas" que têm no KDE e Gnome onde, pelo menos eu, só fico perdido!

[Kobal]

Uma idéia que deviam implementar no portage seria a opção de usar programas no usuario, parecido com o OSX.

Exemplo, um stage1 com as principais ferramentas como root, metalog, rp-pppoe, ppp, iptables, kernel. E o restante como user.

[Vanquirius]

Outro recurso que poderia ser incluído no Portage é a possibilidade de indicar, num ebuild, que alguns de seus pacotes-dependências sejam compilados com determinadas USE flags ativas ou inativas.

Não entendi. Qual é a diferença disso para "built_with_use categoria/pacote flag"?

[Operador Nabla]

Outro recurso que poderia ser incluído no Portage é a possibilidade de indicar, num ebuild, que alguns de seus pacotes-dependências sejam compilados com determinadas USE flags ativas ou inativas.

Não entendi. Qual é a diferença disso para "built_with_use categoria/pacote flag"?

Vou antecipar aqui o que eu pretendia escrever na sala de programação do fórum:

Eu não conhecia esta função, built_with_use, mas presumo que ela sirva para testar se um pacote foi ou não instalado com determinada USE flag ativa, certo?

Em caso afirmativo, metade do que eu havia pensado já está feito. Só faltaria agora estender a notação dos DEPEND atoms para incluir a dependência das USE flags e "aparar algumas arestas". Eu havia pensado em algo assim:

Code: Select all

=my-category/my-package-1.0.0-r2:flag1:flag2:-flag3:flag4:-flag5:-flag6

Neste exemplo, a dependência é satisfeita pelo pacote my-category/my-package-1.0.0-r2 compilado com as USE flags flag3, flag5 e flag6 inativas e as demais indicadas, ativas.

EDIT: A idéia aqui é tirar dos ebuilds a responsabilidade de checar se uma dependência foi compilada com as USE flags desejadas, delegando esta tarefa diretamente ao Portage.

[Vanquirius]

Legal . Seria útil estender a notação, atualmente as ebuilds que eu conheço chamam a função e, em caso negativo, usam die. O seu jeito parece mais correto.