First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 71532
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Mamoru KOMACHI (RETIRED) <usata@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: oberyno <oberyno@gmail.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
_portage_2004-11-17.patch patch to _portage patch oberyno 2004-11-17 07:46 0000 19.88 KB Details | Diff
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 71532 depends on: Show dependency tree
Show dependency graph
Bug 71532 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2004-11-17 07:44 0000
As man portage and emerge --help now refer to actions with --action, I changed
all the actions to _arguments. Now, emerge --ask -d --unmerge will complete the
right set of packages, whereas before, the action had to come first.
Added all the new arguments from new portage versions (--newuse,
--fetch-all-uri, --metadata, --version, --getbinpkg, --getbinpkgonly). I'm not
sure what to do about --getbinpkg{,only}, so it just completes the default
package list.

This patch removes the cache support. Instead, completion searches for
directories and ebuilds matching $PREFIX wherever possible. After "emerge
\=<tab>", only categories will get completed. If one letter is typed, all
categories and ebuilds will be completed that start with said letter. On my
computer(1800+ athlon), cache is a tiny bit faster at "emerge \=g<tab>", but as
soon as more characters are typed, $PREFIX matching becomes just as fast. I
removed cache because I feel it does not provide enough benifit over live
searching. After an "emerge --sync", parts of the cache are wrong and the whole
thing needs to be rebuilt for accuracy.

Instead of sourcing directly, or portageq, I copied what /etc/profile does for
grabbing variables. All variables are kept local and it's as fast as sourcing.
Also, previously, environment variables weren't handled correctly. Setting
PORTDIR in the environment would give the correct completions for the first
<tab>, but the second <tab> would default to what PORTDIR is set to in
make.{conf,globals}.

Removed _portage_clean and _portage_quickpkg as _portage_unmerge{,_vers} are
able to handle both tasks. Well actually, _portage_clean had exact versions
without \= syntax. Now to clean a specific app, a \= is required(portage
understands both \=pkg-ver and pkg-ver for --clean). IMHO, it's confusing to
have different syntax for --unmerge and --clean, I chose the more standard \=
syntax. _portage_clean could certainly be added back if it's functionality is
wanted. Also, "emerge --unmerge <tab>" doesn't complete any versions. The
standard =, >, etc.. are required now. Again, I changed this for consistency
with the rest of portage(and so quickpkg doesn't require it's own function).

Pretty much all actions that can accept arguments now do. --depclean, --sync,
--search and --help now all have the appropriate arguments.

General fixes:
(kv) refers to an associative array, and we have none.
_tags -s: -s is not an argument to _tags.
Removed extra >,=,<=, etc.. logic.
Changed scalars into arrays where appropriate.
Sets and packages will no longer get completed on the same line, so no "emerge
world <tab>" and get packages.
--inject now works properly, although it requires some extra code. I'll be
happy to see it gone.
"emerge app-shell/zsh-completion/<tab>" completes "files". As far as I can
tell, _path_files is incapabale of filtering out just "files"(and not
miscfiles,etc..), so I used an ad-hoc compadd setup. _multi_parts is too slow
for so many packages, and _sep_parts erroneously removes part of $PREFIX
occasionally.
Now that _path_files is gone, overlays have cat/pkg support.
Added cat/pkg completion for \=,>,etc.. context. _sep_parts works fine here,
AFAICT.
Removed rsync.
Moved all emerge related stuff into emerge(){}. So calling ebuild<tab> doesn't
need to figure out all the packages, or emerge arguments.
Removed whitespace from the end of a few lines.

Bugs with new version:
emerge -C<tab> completes all the options. -C was handled by _values previously,
and now _arguments, so I'm not sure if this can or should be fixed.
emerge --oneshot completes sets(world system). AFAICT, _arguments is incapable
of excluding options provided by _values, so the only fix I see would be making
a special case for --oneshot similar to how --unmerge, world and --usepkgonly
are handled. Personally, I think it's a minor bug and not worth the hassle as
portage doesn't complain.
Those are the only two bugs I've found with the current patch, but it changes
alot of code, so I might have broken something.

"rc-update del" only completes init-scripts that are in a runlevel.
Changed "add" to _values to be consistent in appearance with "del". Also,
ignore files that end in .sh.

Well, I think that's it.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

------- Comment #1 From oberyno 2004-11-17 07:46:46 0000 -------
Created an attachment (id=44159) [edit]
patch to _portage

------- Comment #2 From Mamoru KOMACHI (RETIRED) 2004-11-19 13:17:29 0000 -------
Thanks for the update. Yes,  I should have added
your name to authors list ;-)

At first sight, it seems much cleaner than current one. 
As for cache support, I suspected that the cache actually
accelerates completion speed, and thinks it's good to 
remove if it is not necessary. I generally agree with you
on other things you mentioned. (I'll look in detail later)

I'll look into it asap, but I'm afraid it will take at least 
a week as I'm moving out of my home right now.

------- Comment #3 From Mamoru KOMACHI (RETIRED) 2005-02-22 07:46:02 0000 -------
The patch seems identical to _portage patch posted to bug #71957,
and as I applied _portage patch attached there I close this bug.
(tested several weeks so far without a problem)
Thanks oberyno!

First Last Prev Next    No search results available      Search page      Enter new bug