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

2008-12-16 Thread Robert R. Russell
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 Thread Daniel Pielmeier
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 Thread Daniel Pielmeier
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



[gentoo-dev] New global USE flag: gzip-dict

2008-12-16 Thread Peter Volkov
Hello.

Some time ago I've modified stardict.eclass and added optional
possibility based on 'gzip' USE flag to compress index and dict data
files. But I realized too late that I need to document this USE flag
somewhere, and since it'll do similar things for all stardict-*
dictionaries (heh, more than 5 packages...) I'm going to add it as
global USE flag. Also since gzip USE flag already exist in
x11-misc/openclipart I'll change 'gzip' to 'gzip-dict'. So if there will
be no objections I'll add new 'gzip-dict' global USE flag in 2-3 days
from now.

-- 
Peter.




Re: [gentoo-dev] New global USE flag: gzip-dict

2008-12-16 Thread Ciaran McCreesh
On Tue, 16 Dec 2008 22:21:16 +0300
Peter Volkov p...@gentoo.org wrote:
 Some time ago I've modified stardict.eclass and added optional
 possibility based on 'gzip' USE flag to compress index and dict data
 files. But I realized too late that I need to document this USE flag
 somewhere, and since it'll do similar things for all stardict-*
 dictionaries (heh, more than 5 packages...) I'm going to add it as
 global USE flag. Also since gzip USE flag already exist in
 x11-misc/openclipart I'll change 'gzip' to 'gzip-dict'. So if there
 will be no objections I'll add new 'gzip-dict' global USE flag in 2-3
 days from now.

What's the point of having this as an option at all? Is it really
something that affects the end user in any way? Or is it just
gratuitous choisiosity?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] New global USE flag: gzip-dict

2008-12-16 Thread Doug Goldstein

Ciaran McCreesh wrote:

On Tue, 16 Dec 2008 22:21:16 +0300
Peter Volkov p...@gentoo.org wrote:
  

Some time ago I've modified stardict.eclass and added optional
possibility based on 'gzip' USE flag to compress index and dict data
files. But I realized too late that I need to document this USE flag
somewhere, and since it'll do similar things for all stardict-*
dictionaries (heh, more than 5 packages...) I'm going to add it as
global USE flag. Also since gzip USE flag already exist in
x11-misc/openclipart I'll change 'gzip' to 'gzip-dict'. So if there
will be no objections I'll add new 'gzip-dict' global USE flag in 2-3
days from now.



What's the point of having this as an option at all? Is it really
something that affects the end user in any way? Or is it just
gratuitous choisiosity?

  
I happen to be in agreement here. gzip is a quick process, especially 
with a separate index file which would point to a specific section in 
the dict to uncompress. Assuming they've coded it right, it should 
barely be noticeable in the grand scheme of things.


If this is not the case at all and it in fact for some odd reasons 
requires additional deps and requires uncompressing huge files in memory 
such that low memory systems can't handle it, then I'd be in favor of a 
USE flag. But otherwise, it seems like less maintenance for you and less 
user confusion by making it default.




Re: [gentoo-dev] New global USE flag: gzip-dict

2008-12-16 Thread Peter Volkov
В Втр, 16/12/2008 в 19:27 +, Ciaran McCreesh пишет:
 What's the point of having this as an option at all? Is it really
 something that affects the end user in any way?

The reason is that this feature requires additional dependency on
app-text/dictd package (to compress dictionary data dictzip program is
required).

-- 
Peter.




[gentoo-dev] bash version in ebuilds/eclasses...non-compliance and what to do?

2008-12-16 Thread Jeremy Olexa
Exhibit A:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/python.eclass?r1=1.48r2=1.49

This causes me pain on my hosts that don't have =bash-3.1[0] for
/bin/bash. Because I can't install portage with an old bash until I
get a new python installed which uses python.eclass which isn't
supported with my /bin/bash (quite circular indeed)

Technically there are workarounds for me...but it is still annoying.
So...what do we do? A) Specifically allow =bash-3.1 features in
ebuilds/eclasses. or B) revert the commit because the PMS says[1] that
we comply with bash-3.0

Please discuss, thanks.
-Jeremy

[0]: See bash CHANGES file. += is new to bash-3.1
[1]: The ebuild file format is in its basic form a subset of the
format of a bash script. The interpreter is assumed to be GNU bash,
version 3.0 or later. -Chapter 6 Ebuild File Format [2]
[2]: http://dev.gentoo.org/~ferdy/pms/pms-eapi-2-approved-2008-09-25.pdf