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

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

[Paul Varner]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

# Paul Varner <fuzzyray@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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Duncan]

Paul Varner <fuzzyray@gentoo.org> posted
1229371818.21630.7.camel@txslpc1d36.wkst.vzwnet.com, excerpted below, on 
Mon, 15 Dec 2008 14:10:17 -0600:

> # Paul Varner <fuzzyray@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

[Daniel Pielmeier]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

Duncan schrieb am 16.12.2008 00:47:
> Paul Varner <fuzzyray@gentoo.org> posted
> 1229371818.21630.7.camel@txslpc1d36.wkst.vzwnet.com, excerpted below, on 
> Mon, 15 Dec 2008 14:10:17 -0600:
> 
>> # Paul Varner <fuzzyray@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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Douglas Anderson]

On Tue, Dec 16, 2008 at 9:06 AM, Daniel Pielmeier
<daniel.pielmeier@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

[Daniel Pielmeier]

[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]

Douglas Anderson schrieb am 16.12.2008 01:28:
> On Tue, Dec 16, 2008 at 9:06 AM, Daniel Pielmeier
> <daniel.pielmeier@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Daniel Pielmeier]

2008/12/16 Daniel Pielmeier <daniel.pielmeier@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

[Duncan]

Daniel Pielmeier <daniel.pielmeier@googlemail.com> posted
4946FB3F.1090703@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

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

[Daniel Pielmeier]

2008/12/16 Duncan <1i5t5.duncan@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

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

[Duncan]

"Douglas Anderson" <dja@gendja.com> posted
efeb8d230812151628v149d50c9h7483229511e5195e@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.pielmeier@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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Mon, 15 Dec 2008 23:47:47 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

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

md() {
	cat "$(dirname $(equery w $1))/metadata.xml"
}

can also replace cat with less and metadata.xml with ChangeLog, etc.

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Robert R. Russell]

On Monday 15 December 2008 05:47:47 pm Duncan wrote:
> Paul Varner <fuzzyray@gentoo.org> posted
> 1229371818.21630.7.camel@txslpc1d36.wkst.vzwnet.com, excerpted below, on
>
> Mon, 15 Dec 2008 14:10:17 -0600:
> > # Paul Varner <fuzzyray@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

[Daniel Pielmeier]

2008/12/16 Robert R. Russell <nahoy_kbiki@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