Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 67072 - Display info if there is another version in an overlay
Summary: Display info if there is another version in an overlay
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Portage team
Keywords: InVCS
Depends on:
Blocks: 181949
  Show dependency tree
Reported: 2004-10-11 03:46 UTC by Georgi Georgiev
Modified: 2008-02-15 03:47 UTC (History)
1 user (show)

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

portage-2.0.51_rc9-extra-overlay-info.patch (patch,1.36 KB, patch)
2004-10-11 03:52 UTC, Georgi Georgiev
Details | Diff
portage-2.1_rc4-r1-extra-overlay-info.patch (patch-portage-patch,1.38 KB, patch)
2006-06-04 09:42 UTC, Georgi Georgiev
Details | Diff
portage-2.1.1-extra-overlay-info.patch (patch-portage.patch,1.36 KB, patch)
2006-09-15 10:32 UTC, Georgi Georgiev
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Georgi Georgiev 2004-10-11 03:46:46 UTC
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.
Comment 1 Georgi Georgiev 2004-10-11 03:52:24 UTC
Created attachment 41529 [details, diff]

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

$ 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]
Comment 2 Kalin KOZHUHAROV 2004-10-11 05:23:39 UTC
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 :-|
Comment 3 Georgi Georgiev 2006-06-04 09:42:15 UTC
Created attachment 88357 [details, diff]

Rediff against 2.1_rc4-r1 (attachment #41529 [details, diff] works for <=portage-2.1_rc4).
Comment 4 Georgi Georgiev 2006-09-15 10:32:57 UTC
Created attachment 97058 [details, diff]

Rediff against portage-2.1.1
Comment 5 Marius Mauch (RETIRED) gentoo-dev 2007-06-29 09:24:36 UTC
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
Comment 6 Georgi Georgiev 2008-02-15 01:21:37 UTC
Hey, this bug has actually been fixed for a while now. No need to block portage 2.2 anymore.