Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
mask package from an overlay?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
peter4
Guru
Guru


Joined: 19 Jul 2005
Posts: 359
Location: Wroclaw, Poland

PostPosted: Mon Aug 30, 2010 2:23 pm    Post subject: mask package from an overlay? Reply with quote

Hi,

I have an overlay installed (kde-sunset) and there's a package that's both in that overlay and in the main tree (p7zip). I'd like to tell portage to only use ebuilds from the main tree. Can I do that?
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Mon Aug 30, 2010 4:23 pm    Post subject: Reply with quote

Welcome to the piss-poor implementation of overlays for Portage.
It has been like this for what now? 3years? it is pathetic! (only now is there glimmers of some resolution)

Only solution is to ask the overlay maintainers todo a -r0 or something so the inferior masking mechanism that portage exposes can be used
_________________
https://www.otw20.com/ Where you can talk
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
few
Guru
Guru


Joined: 03 Mar 2008
Posts: 448

PostPosted: Mon Aug 30, 2010 7:24 pm    Post subject: Reply with quote

Naib wrote:
Welcome to the piss-poor implementation of overlays for Portage.
It has been like this for what now? 3years? it is pathetic! (only now is there glimmers of some resolution)


[OT]Instead of ranting in the forums you could offer the portage team your help to bring the multirepo branch into a usable shape.[/OT]
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Mon Aug 30, 2010 7:37 pm    Post subject: Reply with quote

few wrote:
Naib wrote:
Welcome to the piss-poor implementation of overlays for Portage.
It has been like this for what now? 3years? it is pathetic! (only now is there glimmers of some resolution)


[OT]Instead of ranting in the forums you could offer the portage team your help to bring the multirepo branch into a usable shape.[/OT]

you are assuming I don't (or use to) talk to the team or that I havn't raise this point a large number of times over the years. At some point you have to stop being helpful because it just falls on deaf ears
_________________
https://www.otw20.com/ Where you can talk
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Wed Sep 01, 2010 8:35 am    Post subject: Reply with quote

Naib wrote:
few wrote:
Naib wrote:
Welcome to the piss-poor implementation of overlays for Portage.
It has been like this for what now? 3years? it is pathetic! (only now is there glimmers of some resolution)


[OT]Instead of ranting in the forums you could offer the portage team your help to bring the multirepo branch into a usable shape.[/OT]

you are assuming I don't (or use to) talk to the team or that I havn't raise this point a large number of times over the years. At some point you have to stop being helpful because it just falls on deaf ears

So this is what an "Advocate" does? :lol:

I have some trouble with overlays occasionally, but I'm glad they are there.
Back to top
View user's profile Send private message
cyrillic
Watchman
Watchman


Joined: 19 Feb 2003
Posts: 7313
Location: Groton, Massachusetts USA

PostPosted: Thu Sep 02, 2010 10:38 pm    Post subject: Re: mask package from an overlay? Reply with quote

peter4 wrote:
there's a package that's both in that overlay and in the main tree (p7zip). I'd like to tell portage to only use ebuilds from the main tree.

Delete the ebuild from the overlay.
You will have to do this each time you sync the overlay, but if it is just one package, it should not be too much trouble.
Back to top
View user's profile Send private message
sips
n00b
n00b


Joined: 08 Apr 2008
Posts: 31

PostPosted: Fri Sep 03, 2010 1:56 am    Post subject: Reply with quote

add PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}" below source /var/lib/layman/make.conf to your /etc/make.conf

for example cut from my make.conf:
Code:
source /var/lib/layman/make.conf
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}"
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /var/local/portage"
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Fri Sep 03, 2010 2:54 am    Post subject: Reply with quote

sips wrote:
add PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}" below source /var/lib/layman/make.conf to your /etc/make.conf

for example cut from my make.conf:
Code:
source /var/lib/layman/make.conf
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}"
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /var/local/portage"


I'm a little slow. Could you please explain why/how this works?
Back to top
View user's profile Send private message
sips
n00b
n00b


Joined: 08 Apr 2008
Posts: 31

PostPosted: Fri Sep 03, 2010 3:08 am    Post subject: Reply with quote

BoneKracker wrote:
sips wrote:
add PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}" below source /var/lib/layman/make.conf to your /etc/make.conf

for example cut from my make.conf:
Code:
source /var/lib/layman/make.conf
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}"
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /var/local/portage"


I'm a little slow. Could you please explain why/how this works?

cause ${PORTDIR} is collated after overlays ${PORTDIR_OVERLAY}, it (the main tree) and its ebuilds will be preferred.
for me, it just works :wink:
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Fri Sep 03, 2010 3:34 am    Post subject: Reply with quote

sips wrote:
BoneKracker wrote:
sips wrote:
add PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}" below source /var/lib/layman/make.conf to your /etc/make.conf

for example cut from my make.conf:
Code:
source /var/lib/layman/make.conf
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}"
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /var/local/portage"


I'm a little slow. Could you please explain why/how this works?

cause ${PORTDIR} is collated after overlays ${PORTDIR_OVERLAY}, it (the main tree) and its ebuilds will be preferred.
for me, it just works :wink:


Let me try, and you can correct me if I'm wrong:

An ebuild from ${PORTDIR_OVERLAY} will be preferred to an ebuild from ${PORTDIR}. That's how portage normally works.

In this case, your trick is that ${PORTDIR_OVERLAY} is expanded to a string that begins with the expansion of ${PORTDIR} (followed by whatever other overlays you are using -- in your case, "/var/local/portage"). So that is going to cause portage to look first in ${PORTDIR} for an ebuild to satisfy the request.

So, the effect of this will be to prefer ebuilds in portage to ebuilds in the overlay (but ebuilds that do not exist in portage will be retrieved from the overlay). We are telling portage, "always try to build from portage, and only use the overlay for stuff that's not in portage".

Question:

So, this would be a good way of applying that as a general rule. But, would it be possible to apply it specifically for one or more given packages only (e.g. by being more specific in what we preprended the ${PORTDIR_OVERLAY} variable with)? For example, let's say you wanted to use everything in the overlay, except for gcc, which you wanted to get from portage instead of the overlay. Would it be possible to use a modified version of your technique to accomplish this?
Back to top
View user's profile Send private message
sips
n00b
n00b


Joined: 08 Apr 2008
Posts: 31

PostPosted: Fri Sep 03, 2010 4:00 am    Post subject: Reply with quote

Quote:
Let me try, and you can correct me if I'm wrong:

An ebuild from ${PORTDIR_OVERLAY} will be preferred to an ebuild from ${PORTDIR}. That's how portage normally works.

In this case, your trick is that ${PORTDIR_OVERLAY} is expanded to a string that begins with the expansion of ${PORTDIR} (followed by whatever other overlays you are using -- in your case, "/var/local/portage"). So that is going to cause portage to look first in ${PORTDIR} for an ebuild to satisfy the request.

So, the effect of this will be to prefer ebuilds in portage to ebuilds in the overlay (but ebuilds that do not exist in portage will be retrieved from the overlay). We are telling portage, "always try to build from portage, and only use the overlay for stuff that's not in portage".

Jep, that's how I use overlays :wink:
Quote:
Question:

So, this would be a good way of applying that as a general rule. But, would it be possible to apply it specifically for one or more given packages only (e.g. by being more specific in what we preprended the ${PORTDIR_OVERLAY} variable with)? For example, let's say you wanted to use everything in the overlay, except for gcc, which you wanted to get from portage instead of the overlay. Would it be possible to use a modified version of your technique to accomplish this?

Hmmm... most likely I'd link or copy gcc from portage to local (over)overlay.
Sorry, I'm just a n00b :oops:
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Fri Sep 03, 2010 4:19 am    Post subject: Reply with quote

sips wrote:
Quote:
Let me try, and you can correct me if I'm wrong:

An ebuild from ${PORTDIR_OVERLAY} will be preferred to an ebuild from ${PORTDIR}. That's how portage normally works.

In this case, your trick is that ${PORTDIR_OVERLAY} is expanded to a string that begins with the expansion of ${PORTDIR} (followed by whatever other overlays you are using -- in your case, "/var/local/portage"). So that is going to cause portage to look first in ${PORTDIR} for an ebuild to satisfy the request.

So, the effect of this will be to prefer ebuilds in portage to ebuilds in the overlay (but ebuilds that do not exist in portage will be retrieved from the overlay). We are telling portage, "always try to build from portage, and only use the overlay for stuff that's not in portage".

Jep, that's how I use overlays :wink:
Quote:
Question:

So, this would be a good way of applying that as a general rule. But, would it be possible to apply it specifically for one or more given packages only (e.g. by being more specific in what we preprended the ${PORTDIR_OVERLAY} variable with)? For example, let's say you wanted to use everything in the overlay, except for gcc, which you wanted to get from portage instead of the overlay. Would it be possible to use a modified version of your technique to accomplish this?

Hmmm... most likely I'd link or copy gcc from portage to local (over)overlay.
Sorry, I'm just a n00b :oops:


You're no noob. You've got an excellent grasp of portage. :lol:
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Fri Sep 03, 2010 8:40 am    Post subject: Reply with quote

sips wrote:
BoneKracker wrote:
sips wrote:
add PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}" below source /var/lib/layman/make.conf to your /etc/make.conf

for example cut from my make.conf:
Code:
source /var/lib/layman/make.conf
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}"
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /var/local/portage"


I'm a little slow. Could you please explain why/how this works?

cause ${PORTDIR} is collated after overlays ${PORTDIR_OVERLAY}, it (the main tree) and its ebuilds will be preferred.
for me, it just works :wink:


That just moves the problem elsewhere. It will give preferential search to the main tree over any overlays BUT what if you want the ebuild from the overlay and they stupidly named it exactly the same as the main tree ( and this occurs quite often).

Only method I have seen that works, for now, is manage your own overlay. Copy the ebuild out of the overlay (luckily most now arch-mask to by default they are disabled) and rename to -r{1,2,3} to provide preference.

One overlay I ran into issue with was the oss overlay for OSSv4. It started bringing in ebuilds completely unrelated to ossv4 with custom patchsets. I have to copy out ossv4 and manage myself
_________________
https://www.otw20.com/ Where you can talk
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
desultory
Bodhisattva
Bodhisattva


Joined: 04 Nov 2005
Posts: 9410

PostPosted: Fri Sep 03, 2010 8:43 am    Post subject: Reply with quote

Why not use post sync hooks to shuffle packages around in local overlays to suit your preferences?
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Fri Sep 03, 2010 9:24 am    Post subject: Reply with quote

Naib wrote:
sips wrote:
BoneKracker wrote:
sips wrote:
add PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}" below source /var/lib/layman/make.conf to your /etc/make.conf

for example cut from my make.conf:
Code:
source /var/lib/layman/make.conf
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}"
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /var/local/portage"


I'm a little slow. Could you please explain why/how this works?

cause ${PORTDIR} is collated after overlays ${PORTDIR_OVERLAY}, it (the main tree) and its ebuilds will be preferred.
for me, it just works :wink:


That just moves the problem elsewhere. It will give preferential search to the main tree over any overlays BUT what if you want the ebuild from the overlay and they stupidly named it exactly the same as the main tree ( and this occurs quite often).


Wait. As far as portage knows, it's getting an ebuild from ${PORDIR_OVERLAY}. If there are two identically-named ebuilds available in ${PORTDIR_OVERLAY}, won't portage take the first one? (Which, given the way he has prepended the variable, would be in fact the one in main tree?)

If that is the case, then handling this is just a matter of making sure your ${PORTDIR_OVERLAY} has your local overlay listed first. Like this make.conf excerpt:
Code:
source /var/lib/layman/make.conf
PORTDIR_OVERLAY="/usr/local/portage ${PORTDIR_OVERLAY}"
Then, in any case where you want an ebuild in the main tree to be preferred to an ebuid in your layman overlays, you could populate your local overlay with a symlink to that application's directory in the main tree (and as long as these preferences are not version-specific, no postsync.d scripts should be required).

Am I wrong about how the overlays work when they contain more than one ebuild with identical names (my assumption that the first one encountered is used)?


Last edited by Bones McCracker on Fri Sep 03, 2010 9:38 am; edited 1 time in total
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Fri Sep 03, 2010 9:31 am    Post subject: Reply with quote

like I said,
What if you want an ebuild from the main tree to have preference AND what if you want another ebuild from an overlay to have preference

You can provide an overall overlay preference (be it gentoo -> sunrise -> oss) BUT that doesn't provide anywhere enough fine-grained control to manage where an ebuild comes from

What if foo-1.2.ebuild existed in gentoo, sunrise and oss and bar-1.2.ebuild existed in gentoo, sunrise and oss AND say you wanted to take foo-1.2 from gentoo but bar-1.2 from sunrise. How could you manage that?

As it stands you cant.
_________________
https://www.otw20.com/ Where you can talk
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Fri Sep 03, 2010 10:08 am    Post subject: Reply with quote

Naib wrote:
like I said,
What if you want an ebuild from the main tree to have preference AND what if you want another ebuild from an overlay to have preference

You can provide an overall overlay preference (be it gentoo -> sunrise -> oss) BUT that doesn't provide anywhere enough fine-grained control to manage where an ebuild comes from

What if foo-1.2.ebuild existed in gentoo, sunrise and oss and bar-1.2.ebuild existed in gentoo, sunrise and oss AND say you wanted to take foo-1.2 from gentoo but bar-1.2 from sunrise. How could you manage that?

As it stands you cant.


I believe you might be able to (if what I am saying is correct about the portage using the first of two identically-named ebuilds in the overlays that it encounters). I would be interested in your comments on this.

If you want an ebuild from the main tree to take preference over the overlays, you pop a symlink to it in your local overlay and it would be preferred to that in your layman overlay. In all other cases, ebuilds from the overlay will take preference over those in the main tree.

You can dream up more complex scenarios, but (if what I am saying about portage using the first ebuild in the overlays is true -- and I'm not sure it is) then they could all be satisfied in that same manner:

Suppose have two separate layman overlays (overlay A and overlay B) with three different ebuilds that exist also in the main portage tree and are identically named (ebuild 1, ebuild 2, and ebuild 3).
Each repository (Portage. A, and B) has a copy of all three ebuilds (1, 2, and 3).

Suppose your preferences are as follows:
You want ebuild 1 from portage
You want ebuild 2 from overlay A
You want ebuild 3 from overlay B

Then, what you would do is this:
Create a symlink in your local overlay to /usr/portage/foo/ebuild1.
Do nothing for ebuild 2.
Create a symlink in your local overlay to /var/lib/layman/foo/ebuild2.

Is it plausible?

[ Edit: doesn't anybody know? Or am I going to have to test this myself? ]
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Sat Sep 04, 2010 1:40 am    Post subject: Reply with quote

BoneKracker wrote:
Naib wrote:
like I said,
What if you want an ebuild from the main tree to have preference AND what if you want another ebuild from an overlay to have preference

You can provide an overall overlay preference (be it gentoo -> sunrise -> oss) BUT that doesn't provide anywhere enough fine-grained control to manage where an ebuild comes from

What if foo-1.2.ebuild existed in gentoo, sunrise and oss and bar-1.2.ebuild existed in gentoo, sunrise and oss AND say you wanted to take foo-1.2 from gentoo but bar-1.2 from sunrise. How could you manage that?

As it stands you cant.


I believe you might be able to (if what I am saying is correct about the portage using the first of two identically-named ebuilds in the overlays that it encounters). I would be interested in your comments on this.

If you want an ebuild from the main tree to take preference over the overlays, you pop a symlink to it in your local overlay and it would be preferred to that in your layman overlay. In all other cases, ebuilds from the overlay will take preference over those in the main tree.

You can dream up more complex scenarios, but (if what I am saying about portage using the first ebuild in the overlays is true -- and I'm not sure it is) then they could all be satisfied in that same manner:

Suppose have two separate layman overlays (overlay A and overlay B) with three different ebuilds that exist also in the main portage tree and are identically named (ebuild 1, ebuild 2, and ebuild 3).
Each repository (Portage. A, and B) has a copy of all three ebuilds (1, 2, and 3).

Suppose your preferences are as follows:
You want ebuild 1 from portage
You want ebuild 2 from overlay A
You want ebuild 3 from overlay B

Then, what you would do is this:
Create a symlink in your local overlay to /usr/portage/foo/ebuild1.
Do nothing for ebuild 2.
Create a symlink in your local overlay to /var/lib/layman/foo/ebuild2.

Is it plausible?

[ Edit: doesn't anybody know? Or am I going to have to test this myself? ]


Symlink to just the ebuild probably wouldn't work (all the additional files and all you know, patches ). HOWEVER the whole directory.

Code:

mkdir -p usr/local/portage/overlay_manage
vi /etc/make.conf
  source /var/lib/layman/make.conf
  PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}"
  PORTDIR_OVERLAY="/usr/local/portage/overlay_manage  ${PORTDIR_OVERLAY} /var/local/portage"


Then something like:
Code:


#!/bin/bash
"
layman_root="/var/lib/layman/"
overlay_manage_root="/usr/local/portage/overlay_manage/"
echo "${2%/*}"

if [[ $1 = gentoo ]]; then
    echo "gentoo overlay switch"
    if [[ -h $overlay_manage_root$2 ]]; then
        echo $overlay_manage_root$2
        rm $overlay_manage_root$2
    fi

elif [[ -d $layman_root$1 ]]; then
    echo "$1 overlay switch"
    if [[ ! -d $overlay_manage_root${2%/*} ]]; then
        mkdir $overlay_manage_root${2%/*}
    fi
    ln -sf $layman_root$1/$2 $overlay_manage_root$2
fi

will allow for easy switching.

overlay_switch gentoo media-sound/mpd

overlay_switch mpd media-sound/mpd
_________________
https://www.otw20.com/ Where you can talk
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sat Sep 04, 2010 9:10 pm    Post subject: Reply with quote

Naib wrote:
Symlink to just the ebuild probably wouldn't work (all the additional files and all you know, patches ). HOWEVER the whole directory.

Yeah, when I said "a symlink to the ebuild", what I meant was, "a symlink to the application's directory".

Naib wrote:

Code:

mkdir -p usr/local/portage/overlay_manage
vi /etc/make.conf
  source /var/lib/layman/make.conf
  PORTDIR_OVERLAY="${PORTDIR_OVERLAY} ${PORTDIR}"
  PORTDIR_OVERLAY="/usr/local/portage/overlay_manage  ${PORTDIR_OVERLAY} /var/local/portage"


That's an interesting idea, but is there really any reason to run a separate "overlay_manage" and "/var/local/portage"? Seems unnecessarily complex. I think all you need is one local overlay, and as long as it is listed before the rest of the ${PORTDIR_OVERLAY}, then it's going to take precedence (allowing you to include such things in it as symlinks, to preempt the normal behavior).

Also, why are you including ${PORTDIR} in the ${PORTDIR_OVERLAY} variable? Won't that cause it to generically prefer ebuilds in the portage tree to any identically-named ebuilds in overlays (unless they are specifically symlinked in overlay_manage)? Seems like it would be better to get rid of ${PORTDIR} and not preempt the overlays by default. (Well -- I guess this all depends on your use case, whether you want to use the overlays by default or not. But using the overlay by default seems closer to the normal behavior of portage to me, so I think it would be better without ${PORTDIR_OVERLAY} in there.

In other words, I think all that's needed is:
Code:

mkdir -p /usr/local/portage/profiles
echo "overlay_local" > /usr/local/portage/profiles/repo_name

vi /etc/make.conf
  source /var/lib/layman/make.conf
  PORTDIR_OVERLAY="/usr/local/portage ${PORTDIR_OVERLAY}"


Then, /usr/local/portage can be used both to "manage" (with symlinks) and to inject modified or custom ebuilds.

I don't think any "switch" mechanism should be required. In those rare cases where there is a conflict, you just put a symlink in the local overlay pointing to application's folder in the appropriate overlay's tree (or the portage tree). Since the local overlay comes first (in the ${PORTDIR_OVERLAY} string, doing this preempts the normal behavior by following the symlink, directing emerge to the desired ebuild.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Sat Sep 04, 2010 10:30 pm    Post subject: Reply with quote

the additional overlay_manage is because my local overlay has alot of custom ebuild (or a scratch area while I fix other ebuilds).
Sure if someone doesn't want their own ebuilds then it is fine (ln acts odd if you name the link to a folder already present).

You don't need to use the overlay_manage, just was a safer testing environment while I knocked that bash script together
_________________
https://www.otw20.com/ Where you can talk
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sat Sep 04, 2010 11:34 pm    Post subject: Reply with quote

Naib wrote:
the additional overlay_manage is because my local overlay has alot of custom ebuild (or a scratch area while I fix other ebuilds).
Sure if someone doesn't want their own ebuilds then it is fine (ln acts odd if you name the link to a folder already present).

You don't need to use the overlay_manage, just was a safer testing environment while I knocked that bash script together


Yeah, but even if you have your own ebuilds, I don't think one needs a separate "manage" overlay. One local overlay is enough (unless you intend to create ebuilds, place them in your local overlay, and then not use them).

And like I said, I don't think the BASH script is necessary, since the use of symlinks in your local overlay performs the function of directing 'emerge' to the desired overlay or to the main portage tree (as long as the local overlay comes first in the ${PORTDIR_OVERLAY} string.



Even if you want to use an overlay only by exception (for example, cherry-picking certain applications from sunrise, while ignoring all the others), you could simply create an alternate layman.cfg file specifying an alternate storage location (for example, /var/lib/layman_alt/ ) which would contain any layman overlays you wish to use only by exception. If you leave this location out of your ${PORTDIR_OVERLAY} variable, it would then never be used except where you have specifically symlinked to it from your local overlay.

One-time setup of the alternate layman storage location:
Code:

# create the alternate layman configuration
cp /etc/layman.cfg /etc/layman_alt.cfg

# specify the alternate storage location
storage   : /var/lib/layman_alt

# populate the alternate storage location:
layman -c /etc/layman_alt.cfg -f -a sunrise


That ought to be it, I think. Then the only thing that would differ from usual is that your period update would include two commands instead of one:
Code:
layman -S
layman -c /etc/layman/layman_alt.cfg -S


Your /etc/make.conf file would remain unchanged (you don't add this overlay to the ${PORTDIR_OVERLAY} variable because you don't want it to be used. For those ebuilds which you want to get from this overlay, you would create a symlink inside your local overlay to the application's directory in the overlay's tree within the alternate storage location. While your regular layman overlays will be used by default, these will not.
Code:
ln -s /usr/local/portage/foo/bar /var/lib/layman_alt/foo/bar)


Am I operating on some incorrect assumption?


Last edited by Bones McCracker on Sun Sep 05, 2010 1:06 am; edited 1 time in total
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Sun Sep 05, 2010 1:02 am    Post subject: Reply with quote

if you want you can go around and manually manage the symlinks.
That bash-script makes it nice and convenient to switch what overlay the default source for the ebuild is.
_________________
https://www.otw20.com/ Where you can talk
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sun Sep 05, 2010 1:32 am    Post subject: Reply with quote

Naib wrote:
if you want you can go around and manually manage the symlinks.
That bash-script makes it nice and convenient to switch what overlay the default source for the ebuild is.


Okay, I see what you're doing there. You are pulling from overlays only by exception. It creates or deletes symlinks from the local overlay (in your case, the manage_overlay). Yes, that would be most useful to automate that. :)

I think the use of such a script would be generally useful in a number of these scenarios.

As you have set it up, it looks like this makes good sense for the scenario where somebody wants to use one or more layman overlays, but only cherry-pick things from them by exception.

Some scenarios (ones that assume use of everything that's in a given overlay by default) might be slightly different (with the script instead creating symlinks to the main portage tree, to preempt the default behavior of installing from the overlay if the ebuild is there).
Back to top
View user's profile Send private message
Bones McCracker
Veteran
Veteran


Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.

PostPosted: Sun Sep 05, 2010 1:52 am    Post subject: Reply with quote

I'm rethinking what I said above about using an alternate layman.cfg file and an alternate storage location. I think this is unnecessary and the right answer is much simpler.

It occurs to me now that all one needs to do to prevent an overlay from being used by default is to manage the /var/lib/layman/make.conf (commenting out or deleting those overlays we only want to use by exception).

Then, all the other overlays will still be used by default, but the one(s) that are commented out won't be.

To cherry-pick from it, as we have been discussing, you'd add symlinks to your local overlay (and your local overlay would be listed first in the ${PORTDIR_OVERLAY} variable, or you'd use a "manage_overlay").
To selectively preempt a certain ebuild from an overlay you otherwise want used by default, you'd create a symlink in the local (or manage) overlay to the appropriate application directory in the main portage tree.

So to cover the broadest range of use cases, I'd want your script to be able to do both of those things (and undo them).

The other question is how to manage the /var/lib/layman/make.conf file. I imagine this file is automatically modified by layman either at the time an overlay is added or removed or at the time layman synchronizes overlays. So any changes to /var/lib/layman/make.conf are probably trashed at that time (I don't know this, I'm only guessing). I'm not sure of the best way to handle that other than manually or by something like a postsync.d script.
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
Page 1 of 1

 
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