To stick with either man or info. Having both, sometimes one is out-dated and the other isn't, and it just makes things somewhat confusing!

Is this a Gentoo issue or a GNU/Linux issue generally? I can't think of any Gentoo-specific utilities that are documented with info pages; info seems to be almost entirely a GNU thing. I find both man and info to be useful and I wouldn't get rid of either of them...please correct me if I am wrong, but what Gentoo program uses info?_________________Draft Windows-to-Linux Guide

Portage should also be able to handle the package order correctly - which it definatly isn't at the moment. (It's very easily noticable these days with all the modular packages - Xorg, gstreamer, xmms plugins, etc. They fail quite often.)

I strongly second the Idea of reverse dependencies in portage. Could be controlled by make.confs FEATURES, like unconditional, where portage acts like current and silently removes the software, warn would act like freebsd ports and print out a warning instead of removing it if other software is dependend on this (could still be overriden with a command line force flag) and revclean, which would also remove all dependend software. Latter one would be hyper-extremely cool, as you could get rid of all of gnome or kde with a simple emerge -C gtk or emerge -C qt.

Further a force-update FEATURE flag could be added, that, if an updated package provides libfoo.so.2, while libfoo.so.1 is installed, forcefully removes libfoo.so.1 and automatically rebuild dependend software. More convinient, albeit more time consuming, than check enotice/elog for old libraries and manually run revdep-rebuild --soname libfoo.so.2

In a next step portage would advance to optionally not only store the package database in a (remote) sql database, but would also be able to perform a fresh install according to the data found there, using either binary or source packages.

You then could add inventory data to that database and create hostgroups with equal configs (kernel, partitioning, etc). up to the point where you just enter a mac address and a hostname into that sql database, insert a minimal gentoo boot floppy (usbstick, whatever) and get a fully automated install. Provided, the client supports pxe boot.

With that, one also could automate updates. A new version of software foo is available, but before rollout it gets compiled and installed on a testbox and if testing was successful, a binary will be created which then gets its clearace and assingnment for a certain hostgroup and upon next boot, that package will be automatically downloaded and installed by all clients belonging to that group. Networkwide, central package management. Would kick serious butt of autoyast, kickstart, ... you name it

Finally, all of portage will be converted to C[++] to get rid of the python dependency for a leaner base system and we are ready to trully rule the world.

But first of all, I'd like to see either an client-only useflag or an /etc/portage/package.server file, in which you can specify for each applicable software, wether you only want the common/client libs or also the server.
Think foremost about common software like samba, openldap, kerberos, postgres, mysql, ntp. Add more at will

I got one important more. For people running no-multilib, get rid of the /lib64 directory and its link. I am pretty sure, /lib, like x86, would do perfectly fine. Is there a /lib64 on alpha or ppc64? I do not know, would be interesting.

/lib64 instead of /lib would be ok, too, but not both - its so annoying as it breaks bash completion

To stick with either man or info. Having both, sometimes one is out-dated and the other isn't, and it just makes things somewhat confusing!

Is this a Gentoo issue or a GNU/Linux issue generally? I can't think of any Gentoo-specific utilities that are documented with info pages; info seems to be almost entirely a GNU thing. I find both man and info to be useful and I wouldn't get rid of either of them...please correct me if I am wrong, but what Gentoo program uses info?

I think its just Linux in general. Both programs from my experiance have about the same features (I think info has a few more), but just being able to use one or the other without have to run both programs. Its one of those features that I think would just be cool to have to trim the system size down a little bit._________________The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.

Is this a Gentoo issue or a GNU/Linux issue generally? I can't think of any Gentoo-specific utilities that are documented with info pages; info seems to be almost entirely a GNU thing. I find both man and info to be useful and I wouldn't get rid of either of them...please correct me if I am wrong, but what Gentoo program uses info?

I think its just Linux in general. Both programs from my experiance have about the same features (I think info has a few more), but just being able to use one or the other without have to run both programs. Its one of those features that I think would just be cool to have to trim the system size down a little bit.

info is much, much more featureful than man. All man can do is display single, flat pages with no link structure at all. info is a full-blown hypertext reader, which was built in an age before the WWW.

man is simple, but not the best tool for distributing voluminous documentation--try navigating "man xterm" to see what I mean.

info works pretty well for distributing long documents. I suppose that if one really wanted to get rid of info, you could take all the info pages and transform them into HTML. These could be read at a console with lynx or with any graphical web browser too. I'm not sure what this transformation would accomplish though. Already most programs have man pages that are good quick-and-dirty summaries, even if the program already has a more in-depth info page. (A good example is tar, whose authors refuse to even write a man page. Debian writes one, though,which is included with most distros.)

If you don't like the info reader (I don't, really) there is an info reader for vim out there. Also Konqueror and the GNOME help reader (forget what it's called) can read both man and info pages. Also, the standard GNU info reader can read both man and info pages, so instead of always typing "man foo" you can always type "info foo" and get the relevant page. Try "info xterm". Problem solved._________________Draft Windows-to-Linux Guide

In a next step portage would advance to optionally not only store the package database in a (remote) sql database, but would also be able to perform a fresh install according to the data found there, using either binary or source packages.

*cough* SCIRE *cough*

Quote:

You then could add inventory data to that database and create hostgroups with equal configs (kernel, partitioning, etc). up to the point where you just enter a mac address and a hostname into that sql database, insert a minimal gentoo boot floppy (usbstick, whatever) and get a fully automated install. Provided, the client supports pxe boot.

*cough* SCIRE *cough*

Quote:

With that, one also could automate updates. A new version of software foo is available, but before rollout it gets compiled and installed on a testbox and if testing was successful, a binary will be created which then gets its clearace and assingnment for a certain hostgroup and upon next boot, that package will be automatically downloaded and installed by all clients belonging to that group. Networkwide, central package management. Would kick serious butt of autoyast, kickstart, ... you name it

*cough* SCIRE *cough*

(Are you sensing a pattern yet? )

Quote:

Finally, all of portage will be converted to C[++] to get rid of the python dependency for a leaner base system and we are ready to trully rule the world.

I love when people mention this one. It's obvious they don't have a clue about how the lower stages are built, or how things like uclibc or embeded work. I'll make it simple. The stage1 tarball has no support for C++, which would mean that portage wouldn't work. It could be written in C, but C++ just wouldn't work.

Quote:

So far, I do not see a boring future for gentoo devs ;o)

I do. Anything dealing with splitting upstream packages is boring as all hell. _________________Ex-Gentoo Developer
Catalyst/Genkernel Development Lead
http://wolf31o2.org

Stuff the news for a package-version in a news/ dir (or file) inside the package's directory. Then have emerge or some other portage tool check for 'new news' after (or before) an `emerge -u` world, kind of like `emerge --changelog`.

Another thing I'd like to see is more maintained packages (or more package maintainers). There are a couple projects I can think of which are very useful/cool (pam-mount and projectM) yet are not in the portage. I had to grab ebuilds for them off bugzilla and tweak them for new releases. I still haven't gotten the new versions of pam-mount working due to 'unresolved symbols' errors when loading it. Other Distros/OSes have things such as pam-mount or projectM and Gentoo should be no exception. I suspect there are some of you who would also like to see their favorite projects accessible under Gentoo (via an overlay or in the main tree) and well maintained.

In a next step portage would advance to optionally not only store the package database in a (remote) sql database, but would also be able to perform a fresh install according to the data found there, using either binary or source packages.

*cough* SCIRE *cough*

Quote:

You then could add inventory data to that database and create hostgroups with equal configs (kernel, partitioning, etc). up to the point where you just enter a mac address and a hostname into that sql database, insert a minimal gentoo boot floppy (usbstick, whatever) and get a fully automated install. Provided, the client supports pxe boot.

*cough* SCIRE *cough*

Quote:

With that, one also could automate updates. A new version of software foo is available, but before rollout it gets compiled and installed on a testbox and if testing was successful, a binary will be created which then gets its clearace and assingnment for a certain hostgroup and upon next boot, that package will be automatically downloaded and installed by all clients belonging to that group. Networkwide, central package management. Would kick serious butt of autoyast, kickstart, ... you name it

*cough* SCIRE *cough*

(Are you sensing a pattern yet? )

Quote:

Finally, all of portage will be converted to C[++] to get rid of the python dependency for a leaner base system and we are ready to trully rule the world.

I love when people mention this one. It's obvious they don't have a clue about how the lower stages are built, or how things like uclibc or embeded work. I'll make it simple. The stage1 tarball has no support for C++, which would mean that portage wouldn't work. It could be written in C, but C++ just wouldn't work.

Quote:

So far, I do not see a boring future for gentoo devs ;o)

I do. Anything dealing with splitting upstream packages is boring as all hell.

Ok, wth is SCIRE?

Also, I think this is funny: how come stage1 doesn't have C++ support? Won't it take only a few extra packages to add in the compatability? For all cases I've seen, C++ works better then C (more features meaning you have to do less hackish work-arounds), unless you just plainly see no need to use C++. Also, has anyone tested to find the diff in speed between a hard-coded Portage, and a scripted one? I know in some cases, scripting can create more overhead, while a hard-coded system works faster, but the convertions can be a pain to make.

Also, about alot of the comments followed by the SCIRE comment, they can be done. Autoinstall would be a simple (over a network), cp <host install system> <hard drive/memory system for system being installed on>. I know alot of the rest can be done right now (via cp and a few other commands)._________________The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.

Portage should also be able to handle the package order correctly - which it definatly isn't at the moment. (It's very easily noticable these days with all the modular packages - Xorg, gstreamer, xmms plugins, etc. They fail quite often.)

Doesn't using emerge -t usually help with this?

What's needed are both of the following emerge options specified together: --update and --deep. The wiki articles for major emerges (that I know about) were updated months ago.

Finally, all of portage will be converted to C[++] to get rid of the python dependency for a leaner base system and we are ready to trully rule the world.

Is that really necessary? I think that part of Portage's success is due to its being written in high-level languages like bash and Python. C[++] would just add a whole host of other low-level issues and complexities that the devs would have to deal with which would distract them from adding new features, like reverse dependency handling. Also, it would take a tremendous effort to port Portage, given its complexity. Even if it were to be ported, they should stick with a high-level language, like Haskell or Prolog (wasn't that considered a while ago?) or something. I say leave that low-level stuff to Python's developers, and let the Portage devs focus on improving our already great package manager .

Finally, all of portage will be converted to C[++] to get rid of the python dependency for a leaner base system and we are ready to trully rule the world.

Is that really necessary? I think that part of Portage's success is due to its being written in high-level languages like bash and Python. C[++] would just add a whole host of other low-level issues and complexities that the devs would have to deal with which would distract them from adding new features, like reverse dependency handling. Also, it would take a tremendous effort to port Portage, given its complexity. Even if it were to be ported, they should stick with a high-level language, like Haskell or Prolog (wasn't that considered a while ago?) or something. I say leave that low-level stuff to Python's developers, and let the Portage devs focus on improving our already great package manager .

The impression I've gotten is that the python code for portage has become such a beast that people are reluctant/afraid/unable to poke at it too much for fear of breaking it. Whether thats a python language thing or just the manner in which it's written I don't know. But I've seen in more than one place that portage would need to be redesigned to allow for the features you refer too.

The impression I've gotten is that the python code for portage has become such a beast that people are reluctant/afraid/unable to poke at it too much for fear of breaking it. Whether thats a python language thing or just the manner in which it's written I don't know. But I've seen in more than one place that portage would need to be redesigned to allow for the features you refer too.

What about creating something similar to NetBSD's pkgsrc, keeping the idea of overlays intact (which as I understand is similar to OpenBSD's FAKE?), and re-writing the whole muck in C/C++/whatever?

If anyone considers it noteworthy, DragonFly BSD seems to be largely moving in this direction, as have a couple Linux distros that i've run across. Main difference being that they've essentially done a direct port of it, but interesting either way._________________Gentoo 2.6.17-r4 AMD64 | AMD Athlon64 3200+ Manchester, 1GB Mushkin PC-3500 Black Hi-Perf Level II, Asus V9999GT 128MB

My biggest problem with gentoo is the way portage handles the removing of meta-packages I.E. if I issue emerge -C kde-meta it shouldn't just remove the meta package but all kde packages and in the case of X.org there should be way to easily revert to monolithic versions as modular has a tendacy to have a plethora of unexpected issues and incompatibilities with older software at this point.

Update the USE flag database! I've got USE flags popping up with emerge -upvDN world that I don't know WHAT they do.

What database? use*.desc should be up2date.

I can understand Dralnu. Few days ago I installed digikam (~x86). It has the Useflag nfs. I take it, because my gallery-directory is on nfs and I want to use it from several computers they mount this share. But if the nfs-useflag is set digikam store his database local in the user-homedirectory instead of the gallery-directory so I can not share it over nfs. If I unset the nfs-useflag it will do what I want. I must try this out and in the docs to the nfs-useflag I cant found this. I mean useflags are the greatest on gentoo, but on serveral packages they will do thinks that never be in the docs and only the ebuild-creator (or who can read and understand the ebuilds) knows what it will do, I think.

Firstly, I'd like to be able to set a filter when using etc-update. Say add a "g" command, which takes a regular expression, after which the command only acts on files that match the pattern. g with no arguments to cancel. Could also have "v" which does a v/re/p and hides all the files that match the regex. I've nearly done this one myself a couple of times. I might yet if folk think it's a good idea. (I tried dispatch-conf - didn't get on with it)

Second thing: I'm not sure if this was covered by an earlier post, but it'd be nice to do emerge --postinstall pkgspec and get any post-installation messages for the package specified. (I read the bit about ELOG, this would still be nice)._________________Don't let THEM immanentize the Eschaton!

Finally, all of portage will be converted to C[++] to get rid of the python dependency for a leaner base system and we are ready to trully rule the world.

Is that really necessary? I think that part of Portage's success is due to its being written in high-level languages like bash and Python. C[++] would just add a whole host of other low-level issues and complexities that the devs would have to deal with which would distract them from adding new features, like reverse dependency handling. Also, it would take a tremendous effort to port Portage, given its complexity. Even if it were to be ported, they should stick with a high-level language, like Haskell or Prolog (wasn't that considered a while ago?) or something. I say leave that low-level stuff to Python's developers, and let the Portage devs focus on improving our already great package manager :D .

Python becomes a massive fallover point for portage and this keeps me from using Gentoo on my main system, I just don't like the idea of me-fucking-up-python-and-not-having-my-package-manager, I'd prefer my package manager be a C application that is STATICALLY linked (note statically, even if I did rm -rf /lib, I could still run the package manager (not that it'd be much use without /lib.....))._________________System: predatorbox
Distro: Arch Linux x86_64
Current projects: blackhole, convmedia and anything else I cook up.

I guess, it will be a job for the rest of my life to sense a patteren there... but yes, at least I sense something; a presence I've not felt since...

About the C or C++ thing, which was btw. the least important of all my notes, its not about speed. Its about a base system should not depend on perl or python, ruby or java or any other funny rad language for stressed, time-to-market-addicted, new economy style web developers (luckily, no prejudice here), solid C and shell should be it. And of course assembler or portable, hand written binary code. The FreeBSD guys already got their enlightement on this matter and kicked out perl, may they safely guide us to the path of eternal light. Hose up your python when updating to 2.5 (example) and enjoy rescuing your system.
But that was just a side note and originally not meant without irony, as this discussion happenede before. One or two times...

And of course you can hack some custom solution to provide automated install and inventory management, as you can always hack something quick and dirty under unix. Preferably using tons of uncommented perl code, devil-may-care and only the geeks survive. Thats what C++ Darwin already said, IIRC.

How uncool would be a standardized, even by lower mere linux mortals implementable solution, working out of the box? At the end of the day we would even have a web interface to manage the complete hard- and software inventory of our hosts and update them, which everybody, even without years experience in unix hacking and database design, can actually use? *shudder*.
No. This would already have a professional touch and as we all know from the daily yellow linux press, gentoo isn't for professionals. Lets keep it that way.

Sure, you are right. Providing that enviroment for portage is as much upstram as apt is for dpkg. However, you still do not want to seperate them. After all, the topic is about improvement for gentoo, not only for portage and those, lets call them addons, for portage, would be exclusively gentoo specific

Nevertheless, the main part, the reverse-dependency thingy remains and of course, my failure, even after breakfast, to figure out the meaning of SCIRE.

Edit: I trully do not have any clue about how lower stages work, I neither would care wether portage would be written in C, Cobj or C++. And if there would be a pascal compiler able to produce statical binaries, even that would be ok for me. Provided, that compiler is available on the same platforms as gcc.

I quit programming when basic losts its line numbering, so I do not even code, neither in C[whatever] nor any high level language and I also do not know wether Ken Thompson and Dennis Ritchie would not code their kernel in php, if they started all over these days.
But until then, low level software should be written in low level languages, as I fancy lean systems with as few dependencies as possible, not as much. Thats why I left debian way back.

And yes, the portable binary code and assembler were supposed to be a joke. Just in case...

The Gentoo handling of meta-packages is *broken*-in fact badly broken.

Once a meta-package has been installed there is no even remotely easy way to remove the deps that got installed when installing the meta-package.

Additionally:

The system/world split, and how these are dealth with by portage, has over time drastically reduced my ability and efficacy to maintain my Gentoo system.

It is but one thing that there is no real handling of reverse dependencies.
It is but one thing that there is no discernible, repeatable order in which packages ares emerged.
It is but one thing that meta-packages, once installed, populate my system with packages, which although related-being dep'ed by the meta-package cannot be uninstalled.
It is but one thing that I have absolutely humonguous package.keyword/packakge.use files which beomce increasingly difficult to manage over time(yes I know of tools which supposedly help -but they have not been helpful for me)

all of these things taken together have profoundly frustrated my experience in adminstering my system.

I really believe the system/world distinction needs to be broken down into somewhat distinct parts

I have 100 odd packages directly related multimedia-when newer versions of underlying multimedia deps come out I have to manually hunt down which ones need to be recompiled.

Although I can install gnome by doing a emerge gnome- I cannot do a emerge -u gnome and expect portage to update to the current versions of the programs which constitute gnome-this never works for me.

I think portage needs some kind of tagging system-which would enable portage to be aware of interelated packages-beyond the question of what the .so file lists as dependencies. mutlimedia ebuilds should clearls be marked with a multimedia tag so that I can say emerge -u multimedia- portage already *knows* what I have installe on my machine- it could take this info and compare it with currently avaialbe versions and update the files appropriately. The sames goes with the desktop-if portage *knows* that gnome(or KDE, or XFCE) is my desktop-and that I have desktop applications(openoffice,firefox, nvu, banshee, beagle, etc.) I should be able to do a emerge -u desktop-and only those packages which pertain directly to the desktop(ie. not the kernel, not mysql, not apache) should be upgraded.

I am quite sure this is impossible-and that there are 10,000 reasons why it is so but I would like to see:

Of course there would be overlapping with reguards to tags-the magic would be in automagically intellegently resolving such overlap-this *magic* is what portage should be.

The idea behind this tagging is to identify groups within portage of approximately 50-100 packages which are related thru their usage-and to tie these together as distinguishable emerge objects. Obviously my suggested list above is specific to my use-but I amsure with a little thought such could be refined to cover the majority of existing use cases amongts the getnoo using population.

I only get angry with Gentoo, when portage becomes my worst enemy-whereas portage is a gift beyond measure when it comes to installing a system, portage is often enemy #1 when it comes to maintaing/upgrading and adminstering said system.

One other last rant: Please remember us users when writing the ebuilds. there was a time long, long ago when I could open a ebuild and manually edit it-to get a newer versions than what is in portage, or to create my own ebuild for a package not yet in portage-back in the day I could grok the ebuilds. So many of the ebuilds today are simply skeletons-all the magic takes places in a extremely complex pertage.eclass relations.Perhaps the reason for this is some aspired "proffesionality" in terms of some much valued supposed "support" which Gentoo is *suppossed* to provide-whatever it is I don't get. Gentoo support for me means these Forums. Gentoo is in my mind a self-help community-and although i dearly appreciate the hard work which gentoo devs put into making Gentoo the best-i hope they remeber that us users have played a pivotal role in making Gentoo what it is today-if for no other reason than that half of the developers at Gentoo came to Gentoo because of the vocal support of Gentoo by people not unlike me. Only once in a blue moon has bugzilla been of any value to me. If nowadays Gentoo is striving to become some kind of proffesional enterprise OS and the price of that is hyper-complicating the ebuild system to the point that us mere mortals can no longer control it I will be moving on to LFS.

Perhaps my tags idea is completely baked. Perhaps these issues are all addressable by one of the many different next-gen portage rewrites. If so you can vanquish these comments to the dust-bin of the internet.

I like the Idea more to be abel to check for categories. lets say like:
emerge -u dev-util/*
That would be more transparent sice I can check on these categories what gets updated.

@ portgae as c app
Well nice thing. first thing I would do is building a portage rpm package for SuSE
But serious wasnt there a try to rewrite emerge in c? I thought I saw something like this on a thread called forgotten apps or something similar. There were also portage clones with database support and stuff.
Maybe makeing portage modular or something would benefit. I mean something like a addonAPI or so to simply add features to portage.
But then again I think emerge =! portage (there is more to portage then emerge) which make this Idea somewhat senseless.

@reverse dependencies.
For a real reverse dependecyx system, wouldnt we need a real database system?
We cant just add all packages in an ebuild. We would create our personal corner of Hell. I think Portage can be a place of it alone. We dont need the devs to dwell with us

But how about having a uninstall-file in portage that is unique to each installed ebuild. If another ebuild installes and has an dependency it just adds itself in the unique uninstaller file. If portage wants to uninstall it simply checks the file and boom knows all reverse stuff it needs to know.
Well I personly think my Idea is dead slow.
(i think I wrote this somewhere else too. But it is not that important to me to go realy after it at this point )

@ useing bugzilla for enhancing.
The main difference is that the ideas here a vague at best. Meybe if they get outlined better we can add an enhancement bug into bugzilla. I see no reasen in produceing hundrets of dupes and bad Idea bugs that get closed right away. Why dont talk this a bit through in comunity first?

Things I would like to see.
Portage working without an internet.
Lets say something like
emerge --sync /mnt/cdrom
and swooop portage gets updated and fetches the sources from CD or something.
Not everyone has a Internet connection 100% up and ready. So it would nice to have an infrastructure to update over CD, usbsticks or whatever none network stuff you can pull into it.
Just a basic Idea._________________quote from Spaceballs:Dark Helmet:[...] we were told to comb the desert, so we're combing it! [puts down bullhorn] Find anything yet?!
Soldier: Nothing yet, sir.

Why not have an ebuild-like system to define package groupings? This way you could use pre-existing groupings or create your own, for lets say all the packages you'd want for a server. Using such a system would make the system install/setup process a breeze.

i know sometimes, after a package is installed, portage displays some (useful) info. however when you emerge several packages in a row you can easily miss this feedback. i suppose it'd be a good idea to prompt a summary of this info at the very end of the emerge process. so that you can read it all at once, without missing anything.

Read the PORTAGE_ELOG section in /etc/make.conf.example

Why do the devs always dismiss this issue? Yes, elog was a step in the right direction, but it could be improved. Why not add an option to display all the elog information at the end of an emerge? That way important messages would not get overlooked, and since it's an option, if you don't want it don't use it. Yes, I have elog set up, and MOST of the time I go and look through the logs. But occasionally I'll forget to look at them, and might miss some important information.

i know sometimes, after a package is installed, portage displays some (useful) info. however when you emerge several packages in a row you can easily miss this feedback. i suppose it'd be a good idea to prompt a summary of this info at the very end of the emerge process. so that you can read it all at once, without missing anything.

Read the PORTAGE_ELOG section in /etc/make.conf.example

Why do the devs always dismiss this issue? Yes, elog was a step in the right direction, but it could be improved. Why not add an option to display all the elog information at the end of an emerge? That way important messages would not get overlooked, and since it's an option, if you don't want it don't use it. Yes, I have elog set up, and MOST of the time I go and look through the logs. But occasionally I'll forget to look at them, and might miss some important information.

GLEP 16, a common menu system, I hate having to build up my fluxbox menu on my own.

There is Kuroo and Porthole, but both are still beta and Porthole has some anoying bugs. A better graphical portage frontend would be cool. (I know, this is not directly a gentoo thing)

Since I read this thread I didn't know about elog, now I am enlightened. So now I propose some better user help, so the users know the tools. Every new user should know about elog!! In fact this is not only limited to elog, often I want a specific feature and am sure that there is some program, but I don't know one (for example I needed a program similar to Outlook for Linux, and didn't know where to search, except google of course. In the end I found evolution. Other example: Is there a good free 3d package? After days of searching, asking and trying I came to the conclusion that Blender is (probably) the best free package out there.). This is again not necessarily not directly related to Gentoo.

A Universe repository (Ubuntu) for Gentoo. I want to quote the Debian unofficial repository site: "One unofficial repository to rule them all."
That's exactly what I want. I guess Sunrise is the number one candidate at the moment. But I guess some official "unofficial repository" would be the best way. Like Ubuntu, they have the universe repository, which is in fact the official unsupported repository.

Bug 139196 -> a better support for ebuilds with CDs.

I can't think of anything else at the moment (except some more and better ebuilds )

Greetings,
moHiJ_________________Even a fool is thought wise if he keeps silent, and discerning if he holds his tongue.
Proverbs 17,28