Re: [gentoo-dev] Re: Last Rites: app-portage/udept
On Monday 15 December 2008 05:47:47 pm Duncan wrote: Paul Varner fuzzy...@gentoo.org posted 1229371818.21630.7.ca...@txslpc1d36.wkst.vzwnet.com, excerpted below, on Mon, 15 Dec 2008 14:10:17 -0600: # Paul Varner fuzzy...@gentoo.org (14 Dec 2008) # Dead upstream, masked for removal in ~30 to 60 days. app-portage/udept Additionally, it doesn't play well with EAPI's greater than zero. The removal bug is Bug #250839. If upstream comes back alive or someone forks and actively maintains, I will unmask or re-add to the tree. Ouch! This one hurts! The main thing I use it for, and therefore the question I have about any useful substitute, is quickly getting a changelog when portage won't spit one out. In particular, when there's a USE flag change in an existing package, or a downgrade, emerge --log won't output anything, because it's not an upgrade. However, I find the info in such logs often useful! Of course I can check the package category and type in the whole long path to the changelog and edit/head/view it by hand, but a quick dep -j pkg is a lot faster and very useful! While I'm at it, is there anything useful to display metadata.xml? In particular, the long descriptions and use flags can be useful. With use.desc and especially the local version thereof going deprecated, and with additional info about global flags sometimes in the metadata... Does anyone have a substitute for udept's clean word file and clean /etc/portage options?
Re: [gentoo-dev] Re: Last Rites: app-portage/udept
2008/12/16 Robert R. Russell nahoy_kb...@hushmail.com: Does anyone have a substitute for udept's clean word file and clean /etc/portage options? With clean world file you mean dep -w or dep --pruneworld and this is what we are already discussing here. eix-test-obsolete is quite usable as replacement for finding out uneeded entries in /etc/portage -- Regards, Daniel
Re: [gentoo-dev] Re: Last Rites: app-portage/udept
2008/12/16 Duncan 1i5t5.dun...@cox.net: FWIW, that's why I originally merged udept. However, by that time I had gotten used to using a set of (local) stub scripts that added in all the appropriate switches, including --oneshot, so once I used udept to clean up the mess I had created before that, as a Gentoo noob, I was fine. I didn't have to worry about using udept for that any more. I'd suggest a similar solution for you, either stub scripts as I use, or make use of EMERGE_DEFAULT_OPTS to put --oneshot in there. If you use the latter, you can then create a stub using --ignore-default-opts --noreplace to add the (presumably already merged) entries to your world file. I actually use --oneshot when merging new stuff now, thus effectively giving me a temporary/testing merge option. Then if I decide to keep it, I run my stub-script to add it to world, and until I either do that or delete it, it stays listed in the --pretend --depclean run I do routinely after my weekly update. =:^) (If you're interested in my stub scripts, mail me offlist and ask. I can tarball them up and send them to you, along with a description of the method to my madness. I've considered creating a proper package for them as I imagine quite a few people would find it useful, but I haven't, yet, and in some ways, they're almost too trivial to package. Maybe if I had someone else test them and tell me whether they found them useful enough to be worth packaging... You may also find Steve Long's emerge helper script useful. It's a bit more featureful than my stub scripts, which are pretty much just bare emerge wrappers. I believe it can be found in the forums.) You are right avoiding this unneeded entries in the world file in the first place is the way to go but somehow these things slip in and then it would be good to have something to find out about it. Also I don't like this kind of wrapper scripts but maybe I should get used to it. Another thing is that I have other stuff set as EMERGE_DEFAULT_OPTS that I probably don't want to miss when using --ignore-default-opts in combination with --noreplace. -- Regards, Daniel
Re: [gentoo-dev] Re: Last Rites: app-portage/udept
Duncan schrieb am 16.12.2008 00:47: Paul Varner fuzzy...@gentoo.org posted 1229371818.21630.7.ca...@txslpc1d36.wkst.vzwnet.com, excerpted below, on Mon, 15 Dec 2008 14:10:17 -0600: # Paul Varner fuzzy...@gentoo.org (14 Dec 2008) # Dead upstream, masked for removal in ~30 to 60 days. app-portage/udept Additionally, it doesn't play well with EAPI's greater than zero. The removal bug is Bug #250839. If upstream comes back alive or someone forks and actively maintains, I will unmask or re-add to the tree. Ouch! This one hurts! ++ I really hope someone steps up and continues maintaining this great tool. Before EAPI's greater than zero existed this tool combined many things I needed for daily use within one single application. The main thing I use it for, and therefore the question I have about any useful substitute, is quickly getting a changelog when portage won't spit one out. In particular, when there's a USE flag change in an existing package, or a downgrade, emerge --log won't output anything, because it's not an upgrade. However, I find the info in such logs often useful! Of course I can check the package category and type in the whole long path to the changelog and edit/head/view it by hand, but a quick dep -j pkg is a lot faster and very useful! While I'm at it, is there anything useful to display metadata.xml? In particular, the long descriptions and use flags can be useful. With use.desc and especially the local version thereof going deprecated, and with additional info about global flags sometimes in the metadata... Regarding metadata.xml there is (besides querying Willikins on IRC) emeta. Take a look at bug 248278 [1]. [1] http://bugs.gentoo.org/show_bug.cgi?id=248278 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Last Rites: app-portage/udept
On Tue, Dec 16, 2008 at 9:06 AM, Daniel Pielmeier daniel.pielme...@googlemail.com wrote: Duncan schrieb am 16.12.2008 00:47: While I'm at it, is there anything useful to display metadata.xml? In particular, the long descriptions and use flags can be useful. With use.desc and especially the local version thereof going deprecated, and with additional info about global flags sometimes in the metadata... Regarding metadata.xml there is (besides querying Willikins on IRC) emeta. Take a look at bug 248278 [1]. [1] http://bugs.gentoo.org/show_bug.cgi?id=248278 emeta will likely become `equery meta' in the next release of gentoolkit, but feel free to use it from the overlay for now. Regarding equery, there's a changes option that is just waiting to be written. Considering udept's changleog function is about 30 lines, it should be trivial to do. If people are interested, I can handle that. It's something I would like to have, also. I hope to have the upgraded gentoolkit available for testing within a few weeks. -Doug
Re: [gentoo-dev] Re: Last Rites: app-portage/udept
Douglas Anderson schrieb am 16.12.2008 01:28: On Tue, Dec 16, 2008 at 9:06 AM, Daniel Pielmeier daniel.pielme...@googlemail.com wrote: Duncan schrieb am 16.12.2008 00:47: While I'm at it, is there anything useful to display metadata.xml? In particular, the long descriptions and use flags can be useful. With use.desc and especially the local version thereof going deprecated, and with additional info about global flags sometimes in the metadata... Regarding metadata.xml there is (besides querying Willikins on IRC) emeta. Take a look at bug 248278 [1]. [1] http://bugs.gentoo.org/show_bug.cgi?id=248278 emeta will likely become `equery meta' in the next release of gentoolkit, but feel free to use it from the overlay for now. Regarding equery, there's a changes option that is just waiting to be written. Considering udept's changleog function is about 30 lines, it should be trivial to do. If people are interested, I can handle that. It's something I would like to have, also. I hope to have the upgraded gentoolkit available for testing within a few weeks. Good to hear! Besides that, is there anything similar to dep --pruneworld. It happens to me sometimes that I forget --oneshot and packages are added to the world file that are not intended to be there. So this option gives an overview over packages in world that have no reverse dependencies and thus are probably not needed. There might still be some packages without reverse dependencies in the world file that are intended to be there because the user wants it there, but being presented with a list of possible unneeded packages it is more easy to determine which are intended to be there and which are not. For checking the reverse dependencies of single packages there is of course emerge -pv --depclean atom, but it is a tedious job to this for every entry in the world file. I hacked something together which runs the above command for every entry in world but this is very slow and dep is much faster doing this check. Regards, Daniel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Last Rites: app-portage/udept
2008/12/16 Daniel Pielmeier daniel.pielme...@googlemail.com: Hm, looks like I have mixed up something here. The pruneworld option looks for packages that _have reverse dependencies_ and thus are probably unneeded and not the other way round Besides that, is there anything similar to dep --pruneworld. It happens to me sometimes that I forget --oneshot and packages are added to the world file that are not intended to be there. So this option gives an overview over packages in world that have reverse dependencies and thus are probably not needed. There might still be some packages with reverse dependencies in the world file that are intended to be there because the user wants it there, but being presented with a list of possible unneeded packages it is more easy to determine which are intended to be there and which are not. For checking the reverse dependencies of single packages there is of course emerge -pv --depclean atom, but it is a tedious job to this for every entry in the world file. I hacked something together which runs the above command for every entry in world but this is very slow and dep is much faster doing this check. -- Regards, Daniel
