You're acting like this is a big deal. Unless I'm missing something, it's
really not.
I don't know how much people know about how Portage calculates its dep tree,
so I'll start from scratch. When you emerge a package, two important (for
our purposes) things happen. 1) a directory in /var/db/pkg is created
containing the current state of a number of Portage variables, including the
USE variables, and the ebuild. 2) If the emerge was done without -u
and --oneshot the package is added to /var/cache/edb/world. How are
dependancy packages handled? As if they had --oneshot. They are not added to
world. (NB: I'm ignoring the system profile)
At this point, emerge -puD world updates all packages, because they are all
in the dependancy graph--that is, every package is installed for a reason.
Either it was manually emerged, or it is a dependancy or of one that was.
What happens when you unmerge this package? Portage uses the /var/db/pkg
ebuild and CONTENTS file to un-install the package. Any dependencies that
you have are *left alone*. This is a much commented-on problem when
removing, for example, kde. Now you have packages on your system that you
don't need, and aren't in the depgraph.
So when you do emerge -puD world they will not be found, because emerge -puD
world is really emerge -puD `cat /var/cache/edb/world`. (again, ignoring the
system profile) But why should they be? Unless you've lied to portage
(removed something from the world file) or there's a portage bug (it removed
it for you when it shouldn't have) nobody really uses any of these--why
update them?
But, you ask, how do I get rid of them? That's what dep-clean is for. It's
in gentoolkit. Run it. I clean my systems out like this: emerge -C
`dep-clean -U -C|grep /` , but you should check which packages you're about
to destroy first. Then run revdep-rebuild, because sometimes there have been
dependency changes without revision bumps (which is, IMO, a bug). Once you
do this, if you still see a deviation, THEN you have a bug. If not, as
usual, I think this is a documentation bug, not a portage bug. Would you
really prefer that Portage waste its time and yours on packages nobody uses?
So, now to address your bug entry.
"The problem of course with executing [2] using qpkg is that all packages
get added to the world file so portage needs to handle this differently."
emerge -uD --oneshot `qpkg -I -nc`
"Deps file - Another will be a 'deps' file in the same location and this
will contain all packages pulled in as a result of a manually installed
package. This 'dependencies' file will also contain all system packages
which form part of the initial base system."
I'm not sure what you mean by this--this is either the difference between
world+system and qpkg -I -nc (i.e., dep-clean -U) , or the
/var/db/pkg/category/package/{,R,P}DEPEND files. Either way, unless I've
misunderstood, it's already available in one way or another.
Finally, there are plenty of things in Gentoo that de facto require a tool
to do them right. There's ufed, mirrorselect, and etc-update. I don't see
why qpkg shouldn't be part of that list if you really, really want to update
all these packages.
-Heschi
> http://bugs.gentoo.org/show_bug.cgi?id=26540
>
> Please read it and provide feedback either on the bug or on this list.
>
> Basically, the issue at hand is the difference between [1] and [2] and how
> portage should handle this difference.
>
> [1] emerge -Duvp world
> [2] emerge -Duvp `qpkg -I -nc`
>
> Look forward to receiving feedback.
--
[EMAIL PROTECTED] mailing list
