Would it be possible to make "emerge -pv" output some flag if the package to be installed has another version in an overlay? Possible scenario: 1. I have adjusted a package to my needs in my overlay 2. A newer version of the package shows up in $PORTDIR 3. I end up updating the package with the version from $PORTDIR that I do not want I know I should be careful when updating, but when there are more packages in my overlay, making the mistake is easy. An example of such adjusted ebuilds include the apache ebuilds (I always change the "suexec-docroot"), and all ebuilds that "fix" Maildir to .maildir. There are also others.
Created attachment 41529 [details, diff] portage-2.0.51_rc9-extra-overlay-info.patch This is a patch that implements the RFE. Sample output looks like this: $ equery -q l -p -o mutt * installed packages [I--] [ ] mail-client/mutt-1.5.6-r3 (0) * Portage tree (/usr/portage) [-P-] [ ] mail-client/mutt-1.4.2.1 (0) [-P-] [ ] mail-client/mutt-1.5.6 (0) [-P-] [M~] mail-client/mutt-1.5.6-r4 (0) [-P-] [ ] mail-client/mutt-vc-query-002 (0) * overlay tree (/usr/portage-chutz /usr/portage-maildir) [--O] [ ] mail-client/mutt-1.5.6-r3 (0) [--O] [ ] mail-client/mutt-1.5.6-r2 (0) # I have two versions in the overlay $ /usr/bin/emerge -vp mutt These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] mail-client/mutt-1.5.6-r3 +cjk +crypt -debug +imap -mbox +nls +nntp +slang +ssl -vanilla 0 kB [2] Total size of downloads: 0 kB Portage overlays: [1] /usr/portage-chutz [2] /usr/portage-maildir # The package to be installed is already from an overlay, so no extra info is displayed $ ACCEPT_KEYWORDS=~x86 /usr/bin/emerge -vp mutt These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] mail-client/mutt-1.5.6-r4 [1.5.6-r3] +cjk +crypt -debug +imap -mbox +nls +nntp +slang +ssl -vanilla 0 kB [o2] Total size of downloads: 0 kB # The package to be installed is from original portage, but there are two other versions in an overlay -- [o2]
Let me add some thoughts that came up after discussing this with Georgi over icq... 1. We (almost) agreed that the worst case is when you overwrite some package installed currently from overlay (t.e. modified by you or someone) with the updated version from $PORTDIR. After some discussion, the only probable way to find out wheather a pkg is installed from $PORTDIR or $PORTDIR_OVERLAY is (example): bzcat /var/db/pkg/net-ftp/proftpd-1.2.9-r2/environment.bz2 |grep EBUILD= and them some heruistics asuming $PORTDIR and $PORTDIR_OVERLAY haven't changed since the pkg was installed. My idea was to check wheather a pkg is installed _currently_ from overlay and indicate it (say version in yellow instead of blue) in some way. An option like --lock-overlay-versions (with a better name) will be good as well. At the moment there is indication if something from overlay is going to be installed, but we need the reverse as well (sth. from overlay is installed) or in the more general case (say 3 overlays :-) what from where is replacing what pkg. Just a quick thought for interface: # emerge ntp -pv [ebuild U ] net-misc/ntp-4.2.0-r33 [4.2.0] -parse-clocks -(selinux) +ssl 0 kB [0=>1] Portage sources: [0] /usr/portage [1] /usr/portage-kalin [2] /usr/portage-chutz ** Asuming less than 9 overlays (reasonable) this will be 6 chars [a=>b] instead of 3 ** 0 is portage itself (logic) ** versions can be different colours depending on their source (t.e. overlay or $PORTDIR) ** an option to upgrade that does not allow changing source dir for ebuild will be handy ** another one disallowing source dir priority (order in $PORTDIR_OVERLAY) lowering! 0=>1, 0=>3, 2=>3 is OK, but 1=>0, 3=>2 is forbidden Now if only somebody codes that in python :-|
Created attachment 88357 [details, diff] portage-2.1_rc4-r1-extra-overlay-info.patch Rediff against 2.1_rc4-r1 (attachment #41529 [details, diff] works for <=portage-2.1_rc4).
Created attachment 97058 [details, diff] portage-2.1.1-extra-overlay-info.patch Rediff against portage-2.1.1
Implemented this in a different way that uses a new entry in the vdb node that stores the _name_ of the repository (set by profiles/repo_name currently), not the path, so it should even work if one changes the locations between installations. If the name is not available (the case with most overlays atm) we display a could-not-determined indicator. Also used the display format outlined in comment #2 (but not the additional logic), except if we're dealing with a new install or if old and new repository are the same, then only the index of the new repository is listed. Some sample outputs (edited for readability): [ebuild N ] sys-process/vixie-cron-4.1-r10 [0] # new install from $PORTDIR [ebuild R ] local-test/etest-2 [?=>1] # reinstall from overlay with unknown old repository [ebuild R ] app-portage/gentoolkit-0.2.4_pre5 [0] # reinstall from $PORTDIR, old repo was also $PORTDIR [ebuild R ] app-portage/gentoolkit-0.2.4_pre5 [0=>1] # reinstall from overlay, old repo was $PORTDIR [ebuild U ] app-portage/gentoolkit-0.2.4_pre5 [0.2.4_pre4] [1=>0] # upgrade using the ebuild from $PORTDIR, while the installed version is from an overlay
Hey, this bug has actually been fixed for a while now. No need to block portage 2.2 anymore. Marking as RESOLVED - FIXED
