Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Overlays priority [solved]
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Mike Lee
n00b
n00b


Joined: 06 Nov 2010
Posts: 6
Location: Russia

PostPosted: Sat Nov 06, 2010 8:28 pm    Post subject: Overlays priority [solved] Reply with quote

Hi all. I've started use layman and found that there is a kind of missing feature in overlays handling (or possible I don't found it). Here is a situation to illustrate observed issue:
For example I have an overlay with a lot of packages. Some of these packages are already integrated to the main tree but cannot be removed from the overlay for some reason (for example there some experimental features, additional use flag testing etc.).

As I understand, when I emerge some package I cannot control from which tree it shall be installed in case if it available in multiple trees. For example I want to use the overlay only for packages which aren't available in the main tree. But as I see, if the same ebuild is available both in the main tree and in the overlay, the overlay always takes priority. Some times ago I saw the situation when the new package version was stabilized in the main tree, but it was still keyworded in the overlay. So I have to wait then the overlay maintainer synchronize it with the main portage tree, or temporary disable the overlay to upgrade the package.

Is my understanding right, or there is some feature to control the overlays?


Last edited by Mike Lee on Sun Nov 07, 2010 8:04 pm; edited 1 time in total
Back to top
View user's profile Send private message
Naib
Advocate
Advocate


Joined: 21 May 2004
Posts: 4423
Location: Removed by Neddy

PostPosted: Sat Nov 06, 2010 11:54 pm    Post subject: Reply with quote

Welcome to one of the flaws in how Gentoo implemented Overlays and the (lack of) management

Oh there has been "means to manage them" talked about and promised for months, dare I say years BUT as of yet NOTHING has appeared.
It really is quite poor how something that is actually quite crucial to the developement of Gentoo is soo poorly supported

Not alot you can do easily. There are a few tricks flying around to manage priorities between categories and overlays but in short Gentoo fail...
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
floppymaster
Developer
Developer


Joined: 07 Jul 2010
Posts: 218
Location: Detroit, MI, USA

PostPosted: Sun Nov 07, 2010 4:36 am    Post subject: Reply with quote

There is a poorly documented way to set an overlay's priority by way of /etc/portage/repos.conf.

For example, if you wanted sunrise to only be used when the package is not in the main tree:
/etc/portage/repos.conf:
[sunrise]
priority = 1001

The main tree has a priority of 1000, and the lowest priority wins.

This works with portage-2.2, not sure about 2.1.
Back to top
View user's profile Send private message
floppymaster
Developer
Developer


Joined: 07 Jul 2010
Posts: 218
Location: Detroit, MI, USA

PostPosted: Sun Nov 07, 2010 4:38 am    Post subject: Reply with quote

Also, you can see the priorities in the output of emerge --info --verbose:
Code:
Repositories:

gentoo
    location: /usr/portage
    sync: rsync://rsync26.us.gentoo.org/gentoo-portage
    priority: 1000

sunrise
    location: /var/lib/layman/sunrise
    masters: gentoo
    priority: -1

floppym
    location: /home/floppym/overlays/floppym
    masters: gentoo
    priority: -2

google-chrome
    location: /home/floppym/overlays/google-chrome
    masters: gentoo
    priority: -3

chromium
    location: /home/floppym/overlays/chromium
    masters: gentoo
    priority: -4

local
    location: /home/floppym/overlays/local
    masters: gentoo
    priority: -5
Back to top
View user's profile Send private message
dol-sen
Developer
Developer


Joined: 30 Jun 2002
Posts: 2685
Location: Richmond, BC, Canada

PostPosted: Sun Nov 07, 2010 5:04 am    Post subject: Reply with quote

Also in portage-2.2 last summers gsoc project to add support for repo deps is partially integrated. I Don't believe it is complete yet. With that integrated you will be able to specify which repo to use, no matter the repo priority setting.

also portage-2.1.9 series is portage-2.2 code based with some incomplete features disabled. It won't be quite as up to date as 2.2, 2.2 will remain a development version for a while yet with 2.1.9 series being it's stable sibling.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...
Back to top
View user's profile Send private message
sera
Developer
Developer


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Sun Nov 07, 2010 8:00 am    Post subject: Re: Overlays priority Reply with quote

Mike Lee wrote:
Is my understanding right, or there is some feature to control the overlays?


There are two options to have full control over the overlays. Fist is to create a local overlay and add it as the only one to PORDIR_OVERLAY in make.conf. Then link the ebuilds you want from other overlays into your local one. The second one is to migrate to paludis.
Back to top
View user's profile Send private message
Mike Lee
n00b
n00b


Joined: 06 Nov 2010
Posts: 6
Location: Russia

PostPosted: Sun Nov 07, 2010 9:31 am    Post subject: Reply with quote

floppymaster wrote:
There is a poorly documented way to set an overlay's priority by way of /etc/portage/repos.conf.

For example, if you wanted sunrise to only be used when the package is not in the main tree:
/etc/portage/repos.conf:
[sunrise]
priority = 1001

The main tree has a priority of 1000, and the lowest priority wins.

This works with portage-2.2, not sure about 2.1.


WOW, I'll try. Thanks a lot.
Back to top
View user's profile Send private message
Mike Lee
n00b
n00b


Joined: 06 Nov 2010
Posts: 6
Location: Russia

PostPosted: Sun Nov 07, 2010 9:34 am    Post subject: Re: Overlays priority Reply with quote

sera wrote:
Mike Lee wrote:
Is my understanding right, or there is some feature to control the overlays?


There are two options to have full control over the overlays. Fist is to create a local overlay and add it as the only one to PORDIR_OVERLAY in make.conf. Then link the ebuilds you want from other overlays into your local one. The second one is to migrate to paludis.


As a first option you mean to use layman only to fetch overlays, but copy required components to own overlay? Possible it's a good choice if you have one or two components.

About migration to paludis, I sounds like "as a second option you can change your distro" :lol:.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Sun Nov 07, 2010 10:21 am    Post subject: Reply with quote

Just for the record, here is the "syntax" explained by means of a (useless) example:
/etc/portage/package.mask wrote:
# Mask all packages of overlay froboz:
*/*::froboz
# Mask slot 2 of package foo/bar in the main tree (but not in any overlay):
foo/bar:2:gentoo
Similar things work in package.accept_keywords and package.unmask.
Back to top
View user's profile Send private message
sera
Developer
Developer


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Sun Nov 07, 2010 10:47 am    Post subject: Re: Overlays priority Reply with quote

Mike Lee wrote:
As a first option you mean to use layman only to fetch overlays, but copy required components to own overlay? Possible it's a good choice if you have one or two components.

Instead of coping I would use symlinks this way it's often a case of set it up once and use forever. This approach is feasible up to many dozens of packages.

For users using the stable branch /etc/portage/repo.conf is often sufficient. However even low priority overlays can wreck havoc given the wrong overlay.

Mike Lee wrote:
About migration to paludis, I sounds like "as a second option you can change your distro" :lol:.


:) Gentoo calls it self a meta distribution. I agree the package manager is an integral part of a distribution, however in case of Gentoo we have the specs(mostly EAPI), the tree, and a reference implementation(portage).

I used the symlink approach myself for a long time to solve this issue. And I certainly would appreciate if one day portage would replace how it deals with overlays with a more mature mechanism.
Back to top
View user's profile Send private message
sera
Developer
Developer


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Sun Nov 07, 2010 10:49 am    Post subject: Reply with quote

mv wrote:
Just for the record, here is the "syntax" explained by means of a (useless) example:
/etc/portage/package.mask wrote:
# Mask all packages of overlay froboz:
*/*::froboz
# Mask slot 2 of package foo/bar in the main tree (but not in any overlay):
foo/bar:2:gentoo
Similar things work in package.accept_keywords and package.unmask.


Which version of portage are you talking about?
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Sun Nov 07, 2010 11:38 am    Post subject: Reply with quote

sera wrote:
Which version of portage are you talking about?

All current 2.2* versions support these features. I don't know which of these have been backported.
Back to top
View user's profile Send private message
sera
Developer
Developer


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Sun Nov 07, 2010 12:07 pm    Post subject: Reply with quote

mv wrote:
sera wrote:
Which version of portage are you talking about?

All current 2.2* versions support these features. I don't know which of these have been backported.


It's not backported then. Does the same syntax work for package.keywords and package.use in 2.2 as well?
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Sun Nov 07, 2010 3:52 pm    Post subject: Reply with quote

sera wrote:
Does the same syntax work for package.keywords and package.use in 2.2 as well?

Yes. I have already written that it works with package.accept_keywords (which is the new name for package.keywords, although the old name is still supported).
Back to top
View user's profile Send private message
floppymaster
Developer
Developer


Joined: 07 Jul 2010
Posts: 218
Location: Detroit, MI, USA

PostPosted: Sun Nov 07, 2010 5:13 pm    Post subject: Reply with quote

mv wrote:
Just for the record, here is the "syntax" explained by means of a (useless) example:
/etc/portage/package.mask wrote:
# Mask all packages of overlay froboz:
*/*::froboz
# Mask slot 2 of package foo/bar in the main tree (but not in any overlay):
foo/bar:2:gentoo
Similar things work in package.accept_keywords and package.unmask.

I think your second example should actually be this:
/etc/portage/package.mask:
# Mask slot 2 of package foo/bar in the main tree (but not in any overlay):
foo/bar:2::gentoo

I believe you always need two colons in front of the repository name. They do not imply an empty slot.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Sun Nov 07, 2010 6:29 pm    Post subject: Reply with quote

floppymaster wrote:
I believe you always need two colons in front of the repository name.

No. The first colon separates the slot and the second colon the overlay name.
Quote:
They do not imply an empty slot.

slot-names cannot be empty, by definition: If there is only one slot, it is usually called "0". An empty slot argument in a package.* file means that every slot applies. This is why "*/*::froboz" means that every slot in every package (of froboz) is masked.
Probably you were confusing the slot with a version number. For instance,
/etc/portage/package.accept_keywords wrote:
=foo/bar-2::froboz

means that version 2 of package foo/bar in the froboz overlay becomes ~ARCH, of course independent of its slot name. If you say instead
/etc/portage/package.accept_keywords wrote:
=foo/bar-2:2:froboz

then the unkeywording only applies if also the slot name of the corresponding version is "2".
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Sun Nov 07, 2010 6:40 pm    Post subject: Reply with quote

BTW: If you want to experiment with the syntax, emerge the most current eix package which should support it and should display the effect immediately... if not, file a bug for eix :wink:
Back to top
View user's profile Send private message
Mike Lee
n00b
n00b


Joined: 06 Nov 2010
Posts: 6
Location: Russia

PostPosted: Sun Nov 07, 2010 8:03 pm    Post subject: Reply with quote

floppymaster wrote:
There is a poorly documented way to set an overlay's priority by way of /etc/portage/repos.conf.

I've just upgrade to portage 2.2.x. Seems like the repos.conf is what I need. Marking this thread as solved.
Back to top
View user's profile Send private message
floppymaster
Developer
Developer


Joined: 07 Jul 2010
Posts: 218
Location: Detroit, MI, USA

PostPosted: Sun Nov 07, 2010 9:28 pm    Post subject: Reply with quote

mv wrote:
No. The first colon separates the slot and the second colon the overlay name.

Wrong. Two consecutive colons indicate the repo (overlay) name.
Code:
floppym@naomi ~ % emerge -pv www-client/chromium:0:gentoo
!!! 'www-client/chromium:0:gentoo' is not a valid package atom.
!!! Please check ebuild(5) for full details.
floppym@naomi ~ % emerge -pv www-client/chromium:0::gentoo

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] www-client/chromium-9999  USE="cups gecko-mediaplayer gnome gnome-keyring -system-sqlite -system-v8" 0 kB [1=>0]

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /home/floppym/overlays/chromium
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Mon Nov 08, 2010 10:26 am    Post subject: Reply with quote

floppymaster wrote:
mv wrote:
No. The first colon separates the slot and the second colon the overlay name.

Wrong. Two consecutive colons indicate the repo (overlay) name.

Currently, I do not have access to a gentoo system. Perhaps there is a bug in parsing the command line. I had tried in /etc/portage/package.*, and the behavior there was certainly the (IMHO logical) one that I described. (IIRC even things like emerge -1 eix::gentoo did not work as expected on the command line, but I had tried that only once and perhaps had made a mistake). So it would be nice to know what is the intended behavior...
Back to top
View user's profile Send private message
floppymaster
Developer
Developer


Joined: 07 Jul 2010
Posts: 218
Location: Detroit, MI, USA

PostPosted: Mon Nov 08, 2010 3:04 pm    Post subject: Reply with quote

Ah, yes, it is definitely possible that the syntax has changed. I have only been playing with it for a month or so.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4707

PostPosted: Mon Nov 08, 2010 9:39 pm    Post subject: Reply with quote

OK, now I have access again to a gentoo system and can confirm that you are right: The syntax really is
Code:
=foo/bar-version:slot::repo
where both, the :slot and ::repo parts, are optional (and of course the =...-version is optional, as usual). The syntax applies to /etc/portage/package.* as well as to the command line. It seems that eix (and maybe my memory :oops: ) needs a fixing...
Back to top
View user's profile Send private message
Spidey
Apprentice
Apprentice


Joined: 07 Sep 2006
Posts: 264

PostPosted: Wed Jul 06, 2011 2:19 am    Post subject: Reply with quote

Sorry for bumping an old thread, but after messing with /etc/portage/repos.conf, my gentoo official tree repository has a -1000 priority. It should be 0, shouldn't it?
Now I'm confused, I don't know for sure if it was that way before, or if repos.conf made this, although I've put in:
Code:
[spidey]
priority -1000


I think it has associated -1000 to the default official portage tree gentoo repository.
Back to top
View user's profile Send private message
floppymaster
Developer
Developer


Joined: 07 Jul 2010
Posts: 218
Location: Detroit, MI, USA

PostPosted: Wed Jul 06, 2011 2:26 am    Post subject: Reply with quote

I think the code relating to repo priorities has changed since I made my post; setting a priority via repos.conf does not seem to work any longer.
Back to top
View user's profile Send private message
rubik-wuerfel
n00b
n00b


Joined: 29 Sep 2004
Posts: 43
Location: Goettingen, Germany

PostPosted: Thu Feb 02, 2012 6:53 pm    Post subject: Reply with quote

floppymaster wrote:
I think the code relating to repo priorities has changed since I made my post; setting a priority via repos.conf does not seem to work any longer.


See this patch, I hope it makes it work again:
https://forums.gentoo.org/viewtopic-p-6946386.html#6946386
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum