there is something I really misslike on GENTOO - the hard way to publicate your ebuilds and find some which aren't in Portage yet.
ok - there is bugzilla - but i don't feel very comfortable with it.

I really like the way which ARCH-Linux goes:
you have several repositorys (current / unstable / extra / community)

a spezial repository "AUR" is the ting I realy like and want to shortly explain:
every user could post his "ebuild". The other Users can rate this community-ebuilds. If a ebuild has
a rate high enough, a TU (trusted User like an gentoo-dev) checks the ebuild an makes it available in the community-rep.
the user which has postet the ebuild first, can take the part of the maintainer an can do updates and such stuff.

i think this is a way, we could get more packages into gentoo and could relieve the DEVs.

what i also misslike is the fact that you need to have always all ebuilds in portage on your local HD !
ARCH has one "text-file" for every repository and downloads the needed ebuilds first when they are needed !
(I know - you can setup exclude-flags in make.conf - but this is not really comfortable !)

Looking for your Opinion
Greetz from snowed Bavaria_________________the german dude with the broken english

If you want non-official ebuilds, just define an overlay directory and use whatever synchronisation method you prefer with that unofficial tree. Many developers have overlays for experimental stuff that doesn't belong into Gentoo yet, and projects exist that provide such ebuilds (like BreakMyGentoo)._________________Please add "[solved]" to the initial topic title when it is solved. TIA.
Linux Sea (PDF), an online e-book on Gentoo Linux

okay, you're right, but what I mean it isn't comfortable to get such ebuilds at all.
If I need a software not in portage, I 've to search the forums, the bugzilla and other sites.
this is really tricky when I'm working on remote machines not having a gui.
Wouldn't it be nice if you could select something similar to this "community" repository where all of this
ebuilds are centraliezed in?

the other thing are the ebuilds in my local portage tree - maybe I use 10-15 Ebuilds of the 580 MB in the /usr/portage dir on my HDs.
okay, HDs are big enought today, but I'm using Gentoo also on devices which have just a Flash-Card with about 128 MB - so it's really
annoying to have always mount your P-Tree over NFS or simmilar to update your machines or to install stuff.

@EarthWings - what is a [troll] ??

thanks for reply_________________the german dude with the broken english

yes, that would be nice. so everybody who want it could setup his overlay with gensync for example.

or what's about making the ebuilds postet in bugzilla available to the commandline?
I' know there is a tool for bugzilla in portage - but can it extract ebuilds?_________________the german dude with the broken english

My suggestion would be simply to set up a website listing popular community overlays, and hope that I find some time to add the modular sync code to portage with overlay support

Why not not make it one large community overlay that is endorsed but not supported by gentoo? I think only the smallest part of gentoo users are aware of the fact that an overlay can be more than a few ebuild they snagged from bugzilla. At least i didn't know that until i started toying around with vdr and someone in irc pointed me towards the gentoo.de overlay.
Plus it might save some redundancy which is inevitable with all those smaller repos

My suggestion would be simply to set up a website listing popular community overlays, and hope that I find some time to add the modular sync code to portage with overlay support

Why not not make it one large community overlay that is endorsed but not supported by gentoo? I think only the smallest part of gentoo users are aware of the fact that an overlay can be more than a few ebuild they snagged from bugzilla. At least i didn't know that until i started toying around with vdr and someone in irc pointed me towards the gentoo.de overlay.
Plus it might save some redundancy which is inevitable with all those smaller repos

Multiple smaller overlays are generally preferrable to one huge combined overlay for several reasons. First every package in an overlay will slow portage down a little bit, so you don't want too many overlay packages, also overlays might contain conflicting packages or dependency mismatches. I'm not talking about a separate overlay for every second package, just group them by topic (e.g. php overlay, java overlay, xgl overlay, "bugzilla" overlay, ...), then everyone can select what he wants.

Though I like your suggestions, I was thinking about yet another feature.. some kind of 'umbrella' package installing system.. the idea is pretty simple, just like 'emerge kde' emerges a bunch of kde programs, it would be nice if we could create our own custom 'umbrella' ebuilds easily, without having to understand ebuild syntax.

We could take an unused character as an 'atom' as I believe it's called.. just like the '=' sign in '=kde-base/kde'. For example, 'kde' would be renamed to '@kde' or something, and after typing a bunch of ebuilds in the file /etc/portage-overlay/umbrella/kde, we could emerge and unmerge all of these packages just simply by emerging @kde. Ofcourse, the defaults would still reside in /usr/portage/umbrella or something.

With this option one could create only a few files with different packages in them, for example /etc/portage-overlay/umbrella/media could contain xmms, mplayer, k3b, etc. These could all be merged and unmerged with 'emerge @media'.

Maybe this way we could even start keeping track of (unused) dependancies.

Just a thought, what do you guys think?_________________Diplomacy is the art of letting the other party have things your way.
-- Daniele Vare

Though I like your suggestions, I was thinking about yet another feature.. some kind of 'umbrella' package installing system.. the idea is pretty simple, just like 'emerge kde' emerges a bunch of kde programs, it would be nice if we could create our own custom 'umbrella' ebuilds easily, without having to understand ebuild syntax.

That's set support, which I hope to get into portage at some point (it's also needed for `emerge security`), but needs a new dep resolver first.

sounds really cool what you guys are writing.would be nice features. The overlay-wiki-page looks awesome, haven't seen it before

but is there a posibility to get the ebuilds-stuff away from my HD? So a new dep-resolver which is able to resolv deps and
first downloads the ebuild when I want to emerge that package?_________________the german dude with the broken english

there is a tool in the portage tree, which helps to handle different overlays using different synchronization methods --- layman
http://projects.gunnarwrobel.de/scripts
it seems to be convenient, but some centralized overlay list would be very helpful

Though I like your suggestions, I was thinking about yet another feature.. some kind of 'umbrella' package installing system.. the idea is pretty simple, just like 'emerge kde' emerges a bunch of kde programs, it would be nice if we could create our own custom 'umbrella' ebuilds easily, without having to understand ebuild syntax.

We could take an unused character as an 'atom' as I believe it's called.. just like the '=' sign in '=kde-base/kde'. For example, 'kde' would be renamed to '@kde' or something, and after typing a bunch of ebuilds in the file /etc/portage-overlay/umbrella/kde, we could emerge and unmerge all of these packages just simply by emerging @kde. Ofcourse, the defaults would still reside in /usr/portage/umbrella or something.

With this option one could create only a few files with different packages in them, for example /etc/portage-overlay/umbrella/media could contain xmms, mplayer, k3b, etc. These could all be merged and unmerged with 'emerge @media'.

Maybe this way we could even start keeping track of (unused) dependancies.

Just a thought, what do you guys think?

that is great...
specialy for newbees that doesn't know well linux programs names...
users could easely build meta-ebuilds for them that gives them a complete and consystent system...
another idea would be to use the exact same thing in order to build images of distributions such as having the same thing as fedora for example(same packages) but the gentoo way...(easyer migration)

i dont know if a wiki is apropriate for this
mabe a php website would be better(as a framwork for summiting and working on ebuilds) but we need some php programers
or if we do a wiki we must at least program some retriving tools for downloading the overlay trees

As I understand things, that looks like a nice feature but is quite complicated to do, even conceptually. The core point of portage is the managing of the dependency tree, and to build such a tree, some info is needed. To get that info on-the-fly, when needed, over the (inter)network, while building or rebuilding the tree is definitely a major challenge. So the info must be on the disk before starting to build the tree. You might think an additional file to the ebuilds, holding that info, could be downloaded first, but I don't think the storage economy you can achieve is worth the rather significant change in gentoo it would require.

To the overlay issue.

As I see it, one of the major "strategic" weaknesses of gentoo is the fact that is is not that easy for software providers, commercial and not commercial, to have a gentoo-version of their packages. Of course, they can submit an ebuild that may find it's way into the official portage tree. But as the number of available packages grows (as we all desire), the load of the maintainers of the official portage tree also grows. At some moment this will become an unpleasant situation for everybody.

I would like an evolution so that every software provider could offer a gentoo version for download, be it the ebuilds themselves or some type of metafile. This metafile could then be user-installed into portage.

For example, the idea behind gensync would be a good starting point, with its /etc/gensync/*.syncsource files.

It could possibly be expanded so that a third party does not need to install a rsync server and an installer for third party syncsource files could do some consistency checking.

Another improvement in the direction I am thinking about could be, in addition to the PORTAGE_OVERLAY directory tree, a PORTAGE_THIRDPARTY directory destinated to third - party packages.

we could also add an "old" overlay that stores all packages that get removed from portage instead of changing some command for preventing the deletion of theses packages
mabe that could be usefull for some persons or purposes

as php website the folowing would be great:
*an ebuild summit
*an automatic ebuild retrivial function(and it's portage tree builder)
*and the folowing ebuild framwork where we can discuss and make comment such as in the gplv3 website

---------------------------------------------------------------------------------
|# Copyright 1999-2005 Gentoo Foundation..........................................................|
|# Distributed under the terms of the GNU General Public License v2..................|
|# $Header: $.............................................................................................................|
|...................................here is the ebuild content.......................................................|.........here the ebuild commant such as the gplv3 one
|....................................................................................................................................|.........or the diff with another version of the ebuild
|....................................................................................................................................|
|....................................................................................................................................|
|....................................................................................................................................|
|....................................................................................................................................|
|....................................................................................................................................|
|....................................................................................................................................|
|....................................................................................................................................|
---------------------------------------------------------------------------------
here a status bar displaying the aceptance by developers
(why it's not acepted in the main tree for example becaust it is a cvs version)
----------------------------------------------------------------------------------
here the general discussion such as bugzilla or forum one
----------------------------------------------------------

*we may also add some diff function...

the main problem would be the browser compatibility because the gplv3 system needs a gecho engine such as firefox

Some problems though:
1) Occasionally there are some packages that seem to give many problems and are marked stable (a good example is the current acroread where many people are complaining about long startup times). Another one that got me about a year ago was the stable nvidia drivers had problems with my card. Even tohugh a lot of people also reported problems and it was acknowledged by nvidia, the package remained marked stable.

2) Also some packages that really excite me seem to take forever to be marked stable.

3) Some less popular packages seem to never be updated. An example of this is slashem. I finally decided to use an overlay to install the newest version, but I usually don't like to do this.

The thing is, Gentoo devs aren't paid and they are doing the best they can. In general things seem to run pretty smooth which is good.

As I understand things, that looks like a nice feature but is quite complicated to do, even conceptually. The core point of portage is the managing of the dependency tree, and to build such a tree, some info is needed. To get that info on-the-fly, when needed, over the (inter)network, while building or rebuilding the tree is definitely a major challenge. So the info must be on the disk before starting to build the tree. You might think an additional file to the ebuilds, holding that info, could be downloaded first, but I don't think the storage economy you can achieve is worth the rather significant change in gentoo it would require.

I guess I am confused....what exactly makes getting the info to manage the dependency tree online difficult? Maybe it would help if I knew how exactly it figures out the tree now. Could someone please explain? Thanks!_________________last.fmSFH, because it's awesome