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 PORTDIR_OVERLAY. 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. Thanks.
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 ways: - 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 want
> 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. 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 set of packages. All of these packages already exist in PORTDIR. I've applied some 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, and 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 seeing 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 the 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. If no 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 that 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 there 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. Plus this just feels hackish/workaroundish, doesn't it? :) It doesn't give me that warm fuzzy feeling inside. > - use RSYNC_EXCLUDEFROM in /etc/make.conf This forces me to maintain essentially the same information in two places -- I 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 not 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 variable. > - use /etc/portage/package.mask to mask any version higher than the one you want Same information in two places, as well. If I understand correctly, that would also cause me to alter package.mask when I do a version/revision bump on my ebuild (perhaps not on revision bumps, would probably be necessary after a major/minor/micro version bump). With PORTDIR_OVERLAY 1st, this becomes unecessary.
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 cd /usr/local/portage rm /etc/portage/rsync_excludefrom for p in */*; do [ -d "$p" ] && echo $p >> /etc/portage/rsync_excludefrom done 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...
