| 1 |
On Wed, 2011-03-30 at 15:22 -0500, Colleen Josephson wrote: |
| 2 |
> I'm interested in expanding the Portage "tags" idea listed on the |
| 3 |
> wiki. |
| 4 |
> To make it SOC-worthy, it obviously needs to be expanded. |
| 5 |
> |
| 6 |
> I have thought of a few possibilities: |
| 7 |
> -Integrate eix into Portage as a replacement to search |
| 8 |
|
| 9 |
I saw the comments on irc, not likey to happen. |
| 10 |
|
| 11 |
> -Add a Debian-apt style autocomplete |
| 12 |
> -Add a flag to force the removal of config files when removing a |
| 13 |
> package, if desired |
| 14 |
|
| 15 |
fairly small feature addition, not much time needed to complete, I |
| 16 |
think. |
| 17 |
|
| 18 |
> -Add a feature that lists which commands were installed after merging |
| 19 |
> a package |
| 20 |
> e.g. after installing net-tools successfully, emerge would say: |
| 21 |
> "Commands in net-tools: arp, hostname, ifconfig, ipmaddr, iptunnel, |
| 22 |
> mii-tool, nameif, netstat, plipconfig, rarp, route and slattach" |
| 23 |
> For packages that install something in /etc/init.d, it would list how |
| 24 |
> to start it: e.g. "To start service, run '/etc/init.d/servicename |
| 25 |
> start'" |
| 26 |
> It would also be nice to have the ability to look this up to see the |
| 27 |
> commands associated with an already installed package: |
| 28 |
> e.g. "emerge --list-commands packagename" or something similar. |
| 29 |
|
| 30 |
Well, the equery command in gentoolkit already does this in the files |
| 31 |
submodule. It also has several builtin filters for the type of file |
| 32 |
your looking for. In this case it would be: |
| 33 |
|
| 34 |
equery files -f cmd $package |
| 35 |
|
| 36 |
|
| 37 |
And since it is coded in python and most of equery uses portage for it's |
| 38 |
information. This would be a trivial addition to portage. But to be |
| 39 |
honest, I think this would be putting too many options to emerge. |
| 40 |
Emerge is already hard pressed for letters to use for short options. |
| 41 |
That and for this task, it would be slower than equery is now, emerge |
| 42 |
has more things to initialize and parse than a basic portage import and |
| 43 |
data query. |
| 44 |
|
| 45 |
|
| 46 |
> |
| 47 |
> I am trying to determine whether or not these features are enough to |
| 48 |
> fill a summer, or if I need more. |
| 49 |
> There are 14 weeks in SOC, 13 weeks of coding if I leave the last week |
| 50 |
> for polishing things. |
| 51 |
> I'm thinking: 3 weeks for eix integration, 1-2 weeks for tags, 1 week |
| 52 |
> for the --remove-config flag, 2-3 weeks for the autocomplete, and 4 |
| 53 |
> weeks for the "commands installed" feature. |
| 54 |
> It looks like I need 1 more "agenda item" to fill the summer. Any |
| 55 |
> suggestions? |
| 56 |
|
| 57 |
If your looking for more portage related projects, have you looked at |
| 58 |
the backend restructure for porthole, project idea? |
| 59 |
|
| 60 |
http://www.gentoo.org/proj/en/userrel/soc/ideas.xml#doc_chap2_sect8 |
| 61 |
|
| 62 |
It will involve coding up a new backend system for porthole so it can |
| 63 |
use a new portage public api for it's data needs as well as be able to |
| 64 |
run merges from within the imported portage code. Once that is working, |
| 65 |
it will then continue to create an interface to pkgcore, so it can be |
| 66 |
used as an alternate PM. |
| 67 |
|
| 68 |
> |
| 69 |
> Do these timeframes sound reasonable? I have 3-4 years of coding |
| 70 |
> experience, with 2 years of Python. |
| 71 |
> |
| 72 |
> I'm in need of a mentor ASAP so I can get feedback while writing up my |
| 73 |
> proposal, and have somebody point me to a good bugfix to do. |
| 74 |
> |
| 75 |
> -- |
| 76 |
> Colleen Josephson |
| 77 |
> Dept. of Electrical Engineering and Computer Science |
| 78 |
> Massachusetts Institute of Technology |
| 79 |
> Class of 2013 |
| 80 |
|
| 81 |
|
| 82 |
-- |
| 83 |
Brian Dolbec <brian.dolbec@×××××.com> |
Archives