Currently, when the portage tree is updated with emerge sync, it removes old ebuilds from your tree. It seems to me that it should exclude the ebuilds of installed packages from being removed. Sometimes I mask all packages newer than a certain version, because a newer version doesn't work for me, but this causes problems once the ebuild has been removed from portage - e.g. emerge world would no longer work since all packages that can satisfy it have been masked. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Want to write a script that generates you a matching rsync_excludes file? Pretty much the same thing portage would need.
I might, but I don't know how (you mean in python or bash?). In fact, I don't even know what an rsync_excludes file is.
/etc/portage/rsync_excludes is the file that portage passes along to the rsync program to the option (--exclude-from=FILE exclude patterns listed in FILE) This file is used to tell rsync to exclude things from your sync tree. Btw adam. if portage installs an ebuild on your system it saves that ebuild to /var/bd/pkg/$packagename/$packagename.ebuild
I'm vote against this. Comparing /usr/portage/... and /var/bd/pkg/... is the only way to detect if an ebuild was removed from the official tree.
OK, how about automatically moving it to another location, outside the portage tree, when an installed package becomes older than the ones in the portage tree? For example, move them to /usr/local/portage. Or maybe add the feature but make it optional, if it would have the potential to cause problems (though I can't think of any - so I would at least think it should be on by default if there's a PORTDIR_OVERLAY defined). At any rate it seems there must be a good way around those problems I originally mentioned.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
The ebuild is currently stored in /var/pkg/db/Category/Package-version/PV.ebuild If this is insufficient, please re-open.
(In reply to comment #7) > The ebuild is currently stored in /var/pkg/db/Category/Package-version/PV. ebuild > > If this is insufficient, please re-open. Er, try /var/db/pkg/... instead, my bad ;)
ebuild (and env) isn't enough, without filesdir being held onto... and potentially files from the eclass dir, ELT-patches fex.
bugspam for closing...
