Bug 84624 – Don't remove ebuilds of installed packages

• Product: Portage Development
• Status: RESOLVED CANTFIX

[Description Adam 2005-03-09 06:00:21 UTC]

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.

[Comment 1 Marius Mauch (RETIRED) 2005-03-09 06:06:14 UTC]

Want to write a script that generates you a matching rsync_excludes file? Pretty much the same thing portage would need.

[Comment 2 Adam 2005-03-09 06:12:17 UTC]

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.

[Comment 3 solar (RETIRED) 2005-03-09 06:27:15 UTC]

/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

[Comment 4 Carsten Lohrke (RETIRED) 2005-03-09 08:19:46 UTC]

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.

[Comment 5 Adam 2005-03-12 18:46:33 UTC]

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.

[Comment 6 Jason Stubbs (RETIRED) 2005-07-28 07:24:38 UTC]

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. ;) 

[Comment 7 Alec Warner (RETIRED) 2005-10-31 19:26:50 UTC]

The ebuild is currently stored in /var/pkg/db/Category/Package-version/PV.ebuild

If this is insufficient, please re-open.

[Comment 8 Alec Warner (RETIRED) 2005-10-31 19:28:41 UTC]

(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 ;)

[Comment 9 Brian Harring (RETIRED) 2005-10-31 19:30:15 UTC]

ebuild (and env) isn't enough, without filesdir being held onto... and
potentially files from the eclass dir, ELT-patches fex.

[Comment 10 Brian Harring (RETIRED) 2005-10-31 19:30:36 UTC]

bugspam for closing...