Most Wanted Portage Feature?

[nadamsieee]

For those silly people who dare to question my choice of choices (?) and pick 'other' , what's your most wanted portage feature?
_________________
nadams (at) ieee (dot) org

[cvk]

It's not really a feature, but I really would like to have a database backend. A simple "qpkg -i -g dev-util" takes bloody ages to complete at the moment.

cvk
_________________
Adopt an unanswered post now.

[scriptkiddie]

My List:
1. MySQL Database Backend (speedier than current system)
2. C/C++ Version of Portage (much quicker)
3. An overall progress bar
4. A way to check the estimated time of complete 'emerge -p filename"
5. To be able to do 'emerge unmerge -dep kde" and get rid of kde and QT
6. I would like to be able to do "emerge -u kde gnome fluxbox" and have it download and install all of them

[Xiol]

1. Reverse deps.
2. Reverse deps.
3. Reverse deps.

You do that, and then I can't complain.

[Genone]

modular portage code
documented portage code
portagefs
EDIT: I forgot something very important:
bugfree portage code

[Genone]

[scriptkiddie]

[nadamsieee]

[scriptkiddie]

I know that.. I was just explaining so that people who don't know what dep packages are would understand what I am talking about

[gsfgf]

it not to take 20 mins to regnerate portag cache after rsyncing.
_________________
Aim:gsfgf0

[noff]

I was actually just coming to post this question.

I think reverse dependencies is really the most necessary, as anyone how has tried to clean gnome or kde off their system.

I think all ideas about how to get a progress meter are ok, but I have a easy stopgap solution until all ebuilds get their btu calculated (which could be automated, see many other posts for btu's). A non-verbose mode I think would make many people happy. Something like...

[gabe]

Reverse deps followed by security for me. The other choices would be nice, but IMHO don't measure up in terms of true usefullness.
_________________
-Gabe
----------
gabe.ef-honda.com

[erik_swanson]

1. Don't pre-generate the cache; build it as the info is needed. Even on my system, the speed increase for dep calcualtion is not worth the time to generate it.
2. Reverse deps.
3. --never-downgrade. An unsafe version of -U that will not honor non-slotted deps like "<cat/libfoo-3.3"
4. Reiser4-based backend. (Put the portage tree in a reiser4 loopback image and use some type of deltas to sync that image)
5. A dep of system that will rm -rf / anyone who bitches about portage being written in python.

[scriptkiddie]

[cvk]

[lamaistres]

I want both, emerge -u security & reverse dependencies. Also, I was thinking about how it would be nice to have a way to emerge gedit (for example) without the extra baggage that comes with it.

[Genone]

[Koon]

1. emerge --security
2. Rev deps
3. Signed tree
4. Speed
5. Accountability (might/should be on a front-end)

-K

[Lovechild]

oh so much is wrong with Portage I don't know where to begin...

1. Trust, there's no trust in portage besides md5sum checks... a man in the middle attack would be easy to stage fx.
2. bye bye FS based portagetree - hello sqlite (or something like it) backend
3. a proper gtk2 frontend
4. per package USE flags instead of global flags (handled in the before mentioned GTK2 frontend)
5. games-roguelike -> games-rpg (silly silly silly)
6. layered overlays
7. threading of emerge (to allow for downloading while we emerge)
8. UUID based internal naming aliased to human readable names (fixes all move, renaming, etc. problems)
9. Gentoo menu item handling system (like Debian, following the freedesktop.org standard maybe?)
10. Sticky flags
11. gtk USE flag for gtk1 deps, gtk2 USE flag for gtk2 deps - it should be that simple, but it's not - this is just SILLY !

those are in no important order what I can think off of the top of my head - but portage could be improved much more than that I think.

[KiTaSuMbA]

[Ari Rahikkala]

[Chris Finch]

7. Reverse deps, 8. R...

OK, seriously: I think that after operation of portage, the system should either be in a state where all dependencies are satisfied or it should spit out which dependencies have yet to be fulfilled.

What I want most of all is a complete, in-detail specification of what portage is supposed to do. It is not documented well at all when it comes to details.

ebuild syntax: at least the part that deals with dependencies, should not allow arbitrary bash commands and variables, in order to facilitate alternative implementations of dependency resolving (that yet would use the ebuild command as a backend).

pinning: I want to be able to install an unstable package and resolve the dependencies in a way such that further unstable packages are only installed if necessary. This is in contrast to the often advertised "ACCEPT_KEYWORDS="~x86" emerge something", which updates ALL dependencies to their latest unstable version, often resulting in completely unnescessary upgrades of, say, xfree. While "emerge insertcompletefilenamehere.ebuild" does that, it stops for every unstable dependency and forces you to merge it in the same manner, which is cumbersome, but still my preferred way to "ACCEPT_...". In addition, the world file should take notice if you wish to follow the unstable branch of a package and notify you when updates are available.

a roll back feature would be nice: Before a major upgrade (like gnome-2.4) you could define the current state of the system as correct, any following unmerges would store the unmerged packages in some place and if compiling the new versions gives you just too many errors you could roll back to the safe state.

USE variables are in many peoples' opinions THE major feature of portage. If only for this reason, all portage commands should be completely USE-aware.

what I need least? more speed. Reasonable people update twice a week, speed is irrelevant, system integrity is what's vital!

I know, this should rather go to bugzilla than to the forums, I have submitted some of the suggestions and so have others, but I wanted to add these ideas to this thread which I was delighted to discover does not contain any of this "rewrite portage in C++ for the sake of speed" nonsense.

[Gandalf_Grey_]

Reverse Dependancies

An overall progress bar, maybe something with ncurses where the top bit of the screen just shows whether a package has been completed or is still compiling.

I am not sure about this but is there away to upgrade to another masked ebuild during an emerge -UDp world iff that ebujild was already masked

Ok perhaps I should explain my dillema, I want to do an emerge -uD world. When I do emerge -uDp world it spends quite a while calculating the stuff then comes up with an error

!!! all ebuilds that could satisfy "=x11-libs/wxGTK-2.4.1*" have been masked.
!!! (dependency required by "dev-python/wxPython-2.4.1.2" [ebuild])

!!! Problem with ebuild net-p2p/bittorrent-theshadow-5.7
!!! Possibly a DEPEND/*DEPEND problem.

!!! Depgraph creation failed.

because packages which satisfy the wxGTK dependancy for wxPhuthon have been masked. If I did accept_keywords="~x86" it woiuld overwrite all my current packages with tthier masked equivilent.
_________________
Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect.
-- Linus Torvalds

[TenPin]

Yeah, reverse deps.

I want to be able to look at a tree like this:

[TheCoop]

We could use a rough idea of emerge time by using something like the LFS bash units (ie, the time it takes to compile bash is recorded, then all other ebuilds have an SBU= variable which lists roughly what percentage of the time taken to compile bash the ebuild takes to complete)

gcc would take ~5 SBUs, kde probably ~20 SBUs...
_________________
95% of all computer errors occur between chair and keyboard (TM)

"One World, One web, One program" - Microsoft Promo ad.
"Ein Volk, Ein Reich, Ein Führer" - Adolf Hitler

Change the world - move a rock