I've always felt a package in PORTDIR_OVERLAY should take
precedence over one in PORTDIR even if there is a newer ebuild
available in PORTDIR for the pacakge. I do realize that there are
other means of accomplishing "version pinning", but I feel that this
behavior would be more convenient and make more sense in the case of
My reasoning is this: If I create a custom ebuild for a particular
package, I do not wish for the work of that ebuild to later be
overwritten or updated unless I create a new revision of the ebuild
and run the update myself. Simply by placing the custom ebuild file in
PORTDIR_OVERLAY, I've taken on the responsibility of maintaining that
particular package, and it seems to me that portage can and should
know not to screw with that, ever :). It seems to me that this would
be the desired behavior more often than not (and perhaps even all the
time), and thus should become the default behavior. Alternatively,
the current behavior could be preserved as the default and a make.conf
toggle could be added that allowed one to use the "Overlay 1st"
behavior. Personally, I can't think of how the current behavior would
be more useful. Any comments on that would be much appreciated, and
let me know if I'm missing some simple reason this would be a bad
idea. I am willing to work on a patch upon request from a developer.
Many people use PORTDIR_OVERLAY just to use new version before it is in portage.
With such a change they wouln't notice updates to packages if they have any
version of them lying in PORTDIR_OVERLAY.
It's easy to avoid updates from packages in PORTDIR, there are even multiple
- use a unrealistic high version number, like foobar-100.ebuild
- use RSYNC_EXCLUDEFROM in /etc/make.conf
- use /etc/portage/package.mask to mask any version higher than the one you
> Many people use PORTDIR_OVERLAY just to use new version before it is in
> With such a change they wouln't notice updates to packages if they have
> version of them lying in PORTDIR_OVERLAY.
Sorry, I somehow overlooked this usage of PORTDIR_OVERLAY. What I'm describing
would definitely have to be an option with the current behavior as the default.
I use PORTDIR_OVERLAY for a somewhat different purpose. I maintain my own
of packages. All of these packages already exist in PORTDIR. I've applied
fairly extensive hacks to the ebuilds of these packages (I have my reasons
where I work). Gentoo gives me the flexibility to do this pretty easily,
that's one reason I love it. Under no circumstances would I want these packages
to get overwritten by a new ebuild in PORTDIR. I'm not too interested in
the updates when i run emerge -up world, either. I maintain them, and accept
full responsibility for applying updates to them and ensuring they fit into
rest of the Gentoo system.
What I'm proposing is (IMO) a more elegant solution to the problem of maintaing
these hacked up packages. Again, I'm not saying that this can't be done through
other means, but that this seems to me a more elegant way of handling it.
one else will use this functionality, leave this WONTFIX and I'll leave you
alone -- it would clearly be extra bloat. I do feel that there are others
might find this useful, however.
I was aware these techniques that you mentioned for "version pinning". I'll
break down why I feel these are less elegant than what I've proposed:
> - use a unrealistic high version number, like foobar-100.ebuild
I've actually used this technique before in conjunction with masking. If
is, for example, a minor version upgrade on the pacakge in PORTDIR, this
technique still causes an "unsanctioned" upgrade of the package, unless you
employ masking as well. Also, once I've taken responsibility of a particular
package, I feel I should be able to use whatever revision numbers I want.
this just feels hackish/workaroundish, doesn't it? :) It doesn't give me
warm fuzzy feeling inside.
> - use RSYNC_EXCLUDEFROM in /etc/make.conf
This forces me to maintain essentially the same information in two places
have to add the ebuild to PORTDIR_OVERLAY and add it to EXCLUDEFROM. It seems
wasteful. Portage can and should (IMO) have the option to know that I do
want the package upgraded with an ebuild from PORTDIR. It already has enough
information to make a judgement without having to use a separate file or
> - use /etc/portage/package.mask to mask any version higher than the one
Same information in two places, as well. If I understand correctly, that
also cause me to alter package.mask when I do a version/revision bump on
ebuild (perhaps not on revision bumps, would probably be necessary after
major/minor/micro version bump). With PORTDIR_OVERLAY 1st, this becomes
I can understand your request, but I don't really see the difference between
adding a new option to change PORTDIR_OVERLAY behavior and using one of the
methods I've listed before. Once we include a global switch there will be
requests to include switches for single packages too.
Also I don't understand some of the problems you mentioned:
1. I didn't mean a high revision number but a high major version number,
unless there are specific dependencies for a lower version this should work
(if necessary add local variables in the ebuild with the real version number).
It's a hack, yes.
2. it's really easy to generate the RSYNC_EXCLUDEFROM file automatic from
your exisiting PORTDIR_OVERLAY contents, just run a little script like the
following before emerge sync and you should be safe
for p in */*; do
[ -d "$p" ] && echo $p >> /etc/portage/rsync_excludefrom
3. ok, I agree that this can be a PITA to maintain.
so option 2 would be IMO be the best for your case.
Let me also explain why I'm so resistant to this proposal:
It would be a major change for a rarely used feature. We would not only need
a new option but also nearly a rewrite of the overlay code. It would also
introduce a lot of special cases that need to be taken care of (like what
to do when there is a package directory in PORTDIR_OVERLAY, but no ebuild
in it?). And as I showed you the functionality is basically already there
in a different way, maybe it's not as nice as emerge --some-new-option but
sufficient for such a special feature.
I hope you understand my reasons.
> It would be a major change for a rarely used feature. We
> would not only need a new option but also nearly a rewrite
> of the overlay code. It would also introduce a lot of
> special cases that need to be taken care of (like what to do
> when there is a package directory in PORTDIR_OVERLAY, but no
> ebuild in it?). And as I showed you the functionality is
> basically already there in a different way, maybe it's not
> as nice as emerge --some-new-option but sufficient for such
> a special feature. I hope you understand my reasons.
Thanks, that's perfectly understandable.
Also, it wasn't so much the labor of maintaining the
separate RSYNC_EXCLUDEFROM that bothered me that much,
rather it was the need to have (essentially) the same
information in two places when it may not have been
necessary. As you've explained, using the script seems a
lesser hack than hacking portage itself. Thanks again...