Welcome to Gentoo Forums, the mailing-list alternative.
https://forums.gentoo.org/
)++brazzmonkey wrote: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...)
This means nothing unless you more precisely explain what "handle" means.Dralnu wrote:Personally, I'd like to see Portage handle reverse deps automatically.
Upstream issue, nothing we're going to solve.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
Code: Select all
FEATURES="noman noinfo"What database? use*.desc should be up2date.Update the USE flag database! I've got USE flags popping up with emerge -upvDN world that I don't know WHAT they do.
The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).R.Smith wrote: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.
Read the PORTAGE_ELOG section in /etc/make.conf.examplebrazzmonkey wrote: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.
Maybe something to do with jingle support in instant messaging?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 wrote:The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).R.Smith wrote: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.
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.mikegpitt wrote: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 wrote:The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).R.Smith wrote: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.
...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.mikegpitt wrote: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 wrote:The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).R.Smith wrote: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.
See my comment above about elog.R.Smith wrote:...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.
What all could I mean by handle? Have it check the reverse deps when unmerging something, or upgrading...Genone wrote:Lets see ...
This means nothing unless you more precisely explain what "handle" means.Dralnu wrote:Personally, I'd like to see Portage handle reverse deps automatically.
Fine.Upstream issue, nothing we're going to solve.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!
The online database is so outdated, it isn't even funny.What database? use*.desc should be up2date.Update the USE flag database! I've got USE flags popping up with emerge -upvDN world that I don't know WHAT they do.
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.The ones you described are not possible for technical reasons (like child processes can't modify the parents environment).R.Smith wrote: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.
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.rodoke wrote: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 wrote: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.rodoke wrote: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>?
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.
cokehabit wrote:oh ffs, haven't you ever seen bugzilla? It has an "enhancement" dropdown menu. Post your problem and how it should be sorted out.
Gentoo IMHO is one of the best distros out there (granted my experiances have been few when it comes to distros).Sachankara wrote: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.
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 wrote: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.
Thanks for the advice, i'll check it out tomorrow. Might save me a couple headachesbeandog wrote: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.
Apparently there is something similar already in existance. Hunt down Man to Info && Info to Man convertion in bugzilla.Dralnu wrote:Gentoo IMHO is one of the best distros out there (granted my experiances have been few when it comes to distros).Sachankara wrote: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.
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...
If you're reading man / info pages in a terminal, check out app-text/pinfo. You can read both with one program.Dralnu wrote:Apparently there is something similar already in existance. Hunt down Man to Info && Info to Man convertion in bugzilla.
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.beandog wrote:If you're reading man / info pages in a terminal, check out app-text/pinfo. You can read both with one program.Dralnu wrote:Apparently there is something similar already in existance. Hunt down Man to Info && Info to Man convertion in bugzilla.
Personally, I just prefer using konqueror to read them both.