What needs to be improved in Gentoo?

[Dralnu]

Ok, we've all seen them. You know, the threads about how Gentoo sucks, and why it sucks, so I'm starting this. If you've got beef with a way something is done, or want to suggest how to improve something, post it. Lets keep it to constructive critism, I have no problem reporting people for trying to start flame wars or trolling. Thank you.

[Dralnu]

Ok, I'll start us off here with a new message.

Personally, I'd like to see Portage handle reverse deps automatically. Revdep-rebuild & emerge -euvDN world will sometimes get things, but us Linux users are notoriously lazy (I mean come on! We script out long task, use cron, ect), and it would also save for many headaches.

More/updated documents and a searchable man/info page section of the website

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!

To continue my previous comment, add in a man_page & info_page USE flags, so that anything you get will be one or the other (also would help reduce system size slightly. Would be handy for like, LiveCDs )

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

Thats all for now

[R.Smith]

You know those messages that are sometimes displayed after emerging a package? Well, I think the ebuilds that do that should automatically do the more trivial ones (such as env-update && source /etc/profile) instead of having the user do it.

[brazzmonkey]

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.

(don't know if i made myself clear on that one...)

[Dralnu]

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.

(don't know if i made myself clear on that one...)

++

I say drop it into a log in /var/logs/, oh, lets just say /var/logs/portage_emerge.log

[Genone]

Lets see ...

Personally, I'd like to see Portage handle reverse deps automatically.

This means nothing unless you more precisely explain what "handle" means.

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!

Upstream issue, nothing we're going to solve.

To continue my previous comment, add in a man_page & info_page USE flags, so that anything you get will be one or the other (also would help reduce system size slightly. Would be handy for like, LiveCDs )

Code: Select all

FEATURES="noman noinfo"

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.

You know those messages that are sometimes displayed after emerging a package? Well, I think the ebuilds that do that should automatically do the more trivial ones (such as env-update && source /etc/profile) instead of having the user do it.

The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).

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

[avieth]

^I think he means the internet database:

http://www.gentoo.org/dyn/use-index.xml

I'm not sure if that's up to date. But most of the USE flags are self explanitory anyways... For example, net-im/kopete has a USE flag called jingle (I think) and it's not listed in the URL above, but I can guess what it does Maybe something to do with jingle support in instant messaging?

I support logging those emerge messages into a /var/*blah* file. Seems like a good, simple idea.

[mikegpitt]

You know those messages that are sometimes displayed after emerging a package? Well, I think the ebuilds that do that should automatically do the more trivial ones (such as env-update && source /etc/profile) instead of having the user do it.

The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).

If communication between processes is a problem, can't portage just pause, and call an external prog to execute these commands, and resume once finished? Also named pipes can be used for the child to communicate with the parent and let the parent handle the execution.

[Genone]

You know those messages that are sometimes displayed after emerging a package? Well, I think the ebuilds that do that should automatically do the more trivial ones (such as env-update && source /etc/profile) instead of having the user do it.

The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).

If communication between processes is a problem, can't portage just pause, and call an external prog to execute these commands, and resume once finished? Also named pipes can be used for the child to communicate with the parent and let the parent handle the execution.

No. The parent here is your shell, not portage (portage is the child). There is no way for portage to execute commands inside your shells context.

[R.Smith]

You know those messages that are sometimes displayed after emerging a package? Well, I think the ebuilds that do that should automatically do the more trivial ones (such as env-update && source /etc/profile) instead of having the user do it.

The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).

If communication between processes is a problem, can't portage just pause, and call an external prog to execute these commands, and resume once finished? Also named pipes can be used for the child to communicate with the parent and let the parent handle the execution.

...or perhaps have a switch for the emerge command that makes portage pause indefinitely at the messages until the user presses return, or something, so that the user can read and react to the messages.

[Genone]

...or perhaps have a switch for the emerge command that makes portage pause indefinitely at the messages until the user presses return, or something, so that the user can read and react to the messages.

See my comment above about elog.

[asiobob]

I'd like to see Java and everything java related improved.
It's already happening, but things like Netbeans are a must, and there are issues with it on Gentoo.
I'd help fix it, but its a real headache, and that explains why it is the way it is

[Dralnu]

Lets see ...

Personally, I'd like to see Portage handle reverse deps automatically.

This means nothing unless you more precisely explain what "handle" means.

What all could I mean by handle? Have it check the reverse deps when unmerging something, or upgrading...

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!

Upstream issue, nothing we're going to solve.

Fine.

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.

The online database is so outdated, it isn't even funny.

Also, the noman noinfo flags would pretty much screw you for docs unless the man/info pages were all converted to one format. IMHO, kind of a useless feature unless you memorized everything in every man/info page, or don't mind hunting down docs online, which can be a chore with some programs.

You know those messages that are sometimes displayed after emerging a package? Well, I think the ebuilds that do that should automatically do the more trivial ones (such as env-update && source /etc/profile) instead of having the user do it.

The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).

R.Smith, I think cfg-update handles the trival (by trivial, I mean formating changes, comments, things that pretty much mean nothing) details automatically. Its unstable (no one will support it atm), but it works from what I know.

I think you can also list config files that you want to auto-update somewhere. Have to do some hunting, though.

[cokey]

oh ffs, haven't you ever seen bugzilla? It has an "enhancement" dropdown menu. Post your problem and how it should be sorted out.

[rodoke]

How about the addition of /etc/portage/package.features? When a package reliably fails with certain features (e.g. distcc, ccache, collision-protect), it'd be nice to have the kind of control I have with package.use and package.keywords.

Speaking of features, how about, say, cleandist+ and cleandist-, that would automatically remove anything downloaded into /usr/portage/distfiles for that package after a successful and unsuccessful merges, respectively.

How about allowing portage to pick randomly from GENTOO_MIRRORS? If the top mirror gets fucked-up in ways that don't cause it to immediately 404 every request, every package gets delayed while they individually time out.

Is there any way we can replace emerge's --skipfirst with, say --skip <n>?

[Dralnu]

How about the addition of /etc/portage/package.features? When a package reliably fails with certain features (e.g. distcc, ccache, collision-protect), it'd be nice to have the kind of control I have with package.use and package.keywords.

Speaking of features, how about, say, cleandist+ and cleandist-, that would automatically remove anything downloaded into /usr/portage/distfiles for that package after a successful and unsuccessful merges, respectively.

How about allowing portage to pick randomly from GENTOO_MIRRORS? If the top mirror gets fucked-up in ways that don't cause it to immediately 404 every request, every package gets delayed while they individually time out.

Is there any way we can replace emerge's --skipfirst with, say --skip <n>?

Actually, seeing Portage messure pings would be nice. Ping each GENTOO_MIRROR, find which is fastest, and use it. If they are tired, then just use the first one on the list, or just use it if there isn't a registering time (like 0.000 seconds?) to speed things up.

I'd like to see a way to check for all installed apps. I know eix -I will show you installed software, but with ~500 packages installed, and 6.98 GB of / and /usr (same partition) out of 11.01 GB, cleaning out programs I don't use would be a dream.

Eclean is a dream, too, lol.

[cokey]

How about the addition of /etc/portage/package.features? When a package reliably fails with certain features (e.g. distcc, ccache, collision-protect), it'd be nice to have the kind of control I have with package.use and package.keywords.

Speaking of features, how about, say, cleandist+ and cleandist-, that would automatically remove anything downloaded into /usr/portage/distfiles for that package after a successful and unsuccessful merges, respectively.

How about allowing portage to pick randomly from GENTOO_MIRRORS? If the top mirror gets fucked-up in ways that don't cause it to immediately 404 every request, every package gets delayed while they individually time out.

Is there any way we can replace emerge's --skipfirst with, say --skip <n>?

Actually, seeing Portage messure pings would be nice. Ping each GENTOO_MIRROR, find which is fastest, and use it. If they are tired, then just use the first one on the list, or just use it if there isn't a registering time (like 0.000 seconds?) to speed things up.

I'd like to see a way to check for all installed apps. I know eix -I will show you installed software, but with ~500 packages installed, and 6.98 GB of / and /usr (same partition) out of 11.01 GB, cleaning out programs I don't use would be a dream.

Eclean is a dream, too, lol.

oh ffs, haven't you ever seen bugzilla? It has an "enhancement" dropdown menu. Post your problem and how it should be sorted out.

[Sachankara]

Portage should have reverse dependency functionality with optional unmerging of older non-used components. 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.)

Less complex init scripts would be nice too, but it'll probably never happend. I'll stick to my own for the time being - they are cleaner and only do what they're supposed to do.

The idea of use flags for man pages and info files would be useful too. There are a few packages that I really want man pages for, while there are many other packages that I don't need any documentation at all for.

Other than that, Gentoo will stay as the distribution of choice for me.

[Dralnu]

Portage should have reverse dependency functionality with optional unmerging of older non-used components. 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.)

Less complex init scripts would be nice too, but it'll probably never happend. I'll stick to my own for the time being - they are cleaner and only do what they're supposed to do.

The idea of use flags for man pages and info files would be useful too. There are a few packages that I really want man pages for, while there are many other packages that I don't need any documentation at all for.

Other than that, Gentoo will stay as the distribution of choice for me.

Gentoo IMHO is one of the best distros out there (granted my experiances have been few when it comes to distros).

Personally, I would like to see a script/program for converting man pages into info pages and vise versa. Thats what I was getting to earlier...

[filterpunk]

Honestly, I don't have too many issues. A couple small niggles, though.

Improved handling of files in /etc - The existing tools do the job, but still leave too much to chance. I feel like i'm spending way too much time ensuring that things don't get clobbered. Sometimes it's small issues, like etc-update trying to clear out my defined /etc/hostname, other times it's more heavy-duty, such as several files pertaining to udev that are receiving multiple changes but don't necessarily explain what's being done or if any further work is required on my part. I haven't had any problems yet, but I always take a deep breath and wish for luck before I start merging things.

For what it's worth, I try to read the documentation regarding these files, I just don't always necessarily understand.

The handbook could also use a couple tweaks. More info on getting better performance from SATA, turning on certain filesystem features and why, as well as designing partition layouts would be quite welcome. Apart from that, the documentation is fantastic, btw!

[beandog]

Improved handling of files in /etc - The existing tools do the job, but still leave too much to chance. I feel like i'm spending way too much time ensuring that things don't get clobbered. Sometimes it's small issues, like etc-update trying to clear out my defined /etc/hostname, other times it's more heavy-duty, such as several files pertaining to udev that are receiving multiple changes but don't necessarily explain what's being done or if any further work is required on my part. I haven't had any problems yet, but I always take a deep breath and wish for luck before I start merging things.

For that, you can use rcs with dispatch-conf (see /etc/dispatch-conf.conf to enable it). At least that way it will keep all the versions of updated files if you ever want to roll back manually.

[filterpunk]

For that, you can use rcs with dispatch-conf (see /etc/dispatch-conf.conf to enable it). At least that way it will keep all the versions of updated files if you ever want to roll back manually.

Thanks for the advice, i'll check it out tomorrow. Might save me a couple headaches

Even though it's fairly new, this thread is turning out to be very beneficial for users and developers, I think. Shows devs where documentation might be lacking (in terms of visibility, anyway) and shows users how they can handle some of the problems they're having that have already been solved.

[Dralnu]

Portage should have reverse dependency functionality with optional unmerging of older non-used components. 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.)

Less complex init scripts would be nice too, but it'll probably never happend. I'll stick to my own for the time being - they are cleaner and only do what they're supposed to do.

The idea of use flags for man pages and info files would be useful too. There are a few packages that I really want man pages for, while there are many other packages that I don't need any documentation at all for.

Other than that, Gentoo will stay as the distribution of choice for me.

Gentoo IMHO is one of the best distros out there (granted my experiances have been few when it comes to distros).

Personally, I would like to see a script/program for converting man pages into info pages and vise versa. Thats what I was getting to earlier...

Apparently there is something similar already in existance. Hunt down Man to Info && Info to Man convertion in bugzilla.

[beandog]

Apparently there is something similar already in existance. Hunt down Man to Info && Info to Man convertion in bugzilla.

If you're reading man / info pages in a terminal, check out app-text/pinfo. You can read both with one program.

Personally, I just prefer using konqueror to read them both.

[Dralnu]

Apparently there is something similar already in existance. Hunt down Man to Info && Info to Man convertion in bugzilla.

If you're reading man / info pages in a terminal, check out app-text/pinfo. You can read both with one program.

Personally, I just prefer using konqueror to read them both.

Well, like I think I stated before, converting everything to one format could help reduce the size of your system (even a little bit) if you don't need either man/info, and the related pages. If you build a LiveCD, that could mean adding in another program, or not.