[gentoo-dev] Last Rites: app-portage/udept

2008-12-15 Thread Paul Varner
# 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.

Regards,
Paul Varner



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-12-15 Thread Joe Peterson
Donnie Berkholz wrote:
 On 15:35 Mon 01 Dec , Joe Peterson wrote:
 However, what I see as perhaps a missing piece is more conceptual: the
 important connection between the valuable info in the emerge logs (and their
 somewhat transient default nature) and what a user looks for when he/she has 
 a
 problem with a package.  Yes, users will realize this as they use Gentoo (and
 will start paying more attention to logs as a result), so I don't think it's 
 a
 huge problem, but what this particular user said to me made me think that
 there is, perhaps, an opportunity to improve the situation.
 
 Based on the rarity of me seeing this reported as a problem, I'm 
 inclined to think it says more about this user than about our system.

This could very-well be.  However:

 I don't think it's our responsibility to put documentation everywhere 
 someone might conceivably look for information.

I agree with this statement, but I wasn't implying we should duplicate
information everywhere.  I wanted to explore this as an opportunity to
re-think if having an official de facto spot for gentoo readmes
would make sense, thereby saving log output in a useful place where
users would learn to look regularly.  I agree this would only be
reasonable if it were the right thing, architecturally, for Gentoo, not
just for this one user's issue.

-Joe



[gentoo-dev] Re: [RFC] Saving package emerge output (einfo, elog, ewarn, etc.) somewhere official

2008-12-15 Thread Duncan
Joe Peterson lava...@gentoo.org posted 4946dd7f.80...@gentoo.org,
excerpted below, on  Mon, 15 Dec 2008 15:43:11 -0700:

 I don't think it's our responsibility to put documentation everywhere
 someone might conceivably look for information.
 
 I agree with this statement, but I wasn't implying we should duplicate
 information everywhere.  I wanted to explore this as an opportunity to
 re-think if having an official de facto spot for gentoo readmes
 would make sense, thereby saving log output in a useful place where
 users would learn to look regularly.  I agree this would only be
 reasonable if it were the right thing, architecturally, for Gentoo, not
 just for this one user's issue.

That suggests an interesting possibility to me.  Let's see if anyone else 
likes it.

What about some place on the web, maybe on packages, having a single 
location with all the standard messages, listed by package and version.  
I'm picturing a single reference location where someone can look up the 
package and see all the routine postinst messages, etc, that it spits 
out.  Perhaps treat metapackages such that they group together all the 
messages from the collected sub-packages.

Then when we (as users) think about a big upgrade, we can go and research 
just what sort of thing the package maintainers already anticipate, and 
can thus better prepare ourselves.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




[gentoo-dev] Re: Last Rites: app-portage/udept

2008-12-15 Thread Duncan
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...

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




Re: [gentoo-dev] Re: Last Rites: app-portage/udept

2008-12-15 Thread Daniel Pielmeier
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

2008-12-15 Thread Douglas Anderson
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

2008-12-15 Thread Daniel Pielmeier
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-15 Thread Daniel Pielmeier
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



[gentoo-dev] Re: Last Rites: app-portage/udept

2008-12-15 Thread Duncan
Douglas Anderson d...@gendja.com posted
efeb8d230812151628v149d50c9h7483229511e51...@mail.gmail.com, excerpted
below, on  Tue, 16 Dec 2008 09:28:30 +0900:

 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?

 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

Thanks!

 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.

Very good, thanks!  I'm definitely looking forward to it! =:^)

(BTW, I wrote emerge --log when I should have written --changelog, but it 
looks like everyone realized what I meant.)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




[gentoo-dev] Re: Last Rites: app-portage/udept

2008-12-15 Thread Duncan
Daniel Pielmeier daniel.pielme...@googlemail.com posted
4946fb3f.1090...@googlemail.com, excerpted below, on  Tue, 16 Dec 2008
01:50:07 +0100:

 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.

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.)

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman