Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 84624 - Don't remove ebuilds of installed packages
Summary: Don't remove ebuilds of installed packages
Status: RESOLVED CANTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-09 06:00 UTC by Adam
Modified: 2005-10-31 19:30 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 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 archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 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 gentoo-dev 2005-10-31 19:30:36 UTC
bugspam for closing...