In Debian, you can give apt-get additional sources from which to check for applications to install. In a similar manner, why not have the same for Gentoo? The only essential feature needed are already there; overlay directories. Code: # vim /etc/make.conf ----------------------------------------------------- # alternate rsync servers bmg rsync.breakmygentoo.net /usr/portage/local/bmg/ ----------------------------------------------------- # emerge --sync bmg Much easier than having to download stuff manually from BMG or indeed anywhere else. It would also make it really simple for the Gentoo devs to have an automatic 'development' repository that people could delve into. Further discussion available in the forums: http://forums.gentoo.org/viewtopic.php?t=84478
Ok, I looked a bit into it and my approach is a bit different: a) instead of a paramter for the --sync action use a new --ovsync action to sync overlay directories b) introduce a new SYNC_OVERLAY variable that corresponds to PORTDIR_OVERLAY, where the special values "none" and "local" disable any sync actions for the overlays c) use the existing sync code for this feature little example: in make.conf I have PORTDIR_OVERLAY="/usr/local/portage/cvs /usr/local/portage/bmg /usr/local/portage/test" SYNC_OVERLAY="cvs://user@server:/cvsroot:module rsync://rsync.breakmygentoo.net local" - emerge --sync works as normal - on emerge --ovsync /usr/local/portage/cvs and /usr/local/portage/bmg get synced with the specified cvs and rsync servers This approach has several advantages: - syntax is better suited for make.conf / bash - most of the code already exists - easier to implement - support for cvs repositories - is backwards compatible to the existing OVERLAY stuff It also has some disadvantages: - needs an overhaul of the cvs sync code (but that looks broken to me anyway) - syncs all overlays - you have to maintain two variables for each overlay Comments welcome.
*** Bug 11165 has been marked as a duplicate of this bug. ***
No comments, so I guess everyone likes it ;) Will do it this way then (already had it working with cvs but lost the patch when upgrading to -r5 :( )
Ya, i wondered about that for a second because i did remember searching for something like this when i posted it. after readin the other bug report though, seems like more was going on there so i didnt worry about it anymore :)
Created attachment 18255 [details, diff] patch for syncing PORTDIR_OVERLAY directories set variables in make.conf: PORTDIR_OVERLAY="/usr/local/portage-local /usr/local/portage-bmg" SYNC_OVERLAY="local rsync://rsync.breakmygentoo.net/portage" (of course this will only work if the remote location exists) You can also use the cvs://user@server:cvsroot:module syntax.
I like this feature. :) I'd like to distribute my ebuilds for test. But I like simple setting for user. My idea is ... PORTDIR_OVERLAY="/usr/local/portage/cvs|cvs://user@server:/cvsroot:module /usr/local/portage/bmg|rsync://rsync.breakmygentoo.net /usr/local/portage/test" You would do: # emerge sync /usr/local/portage/cvs # emerge sync /usr/local/portage/bmg What do you think?
ok, I'm currenty rewriting the complete emerge sync code (as I'm adding a bunch of other features as well), I'll likely end up with a auxiliary file in /etc/portage that describes the relations between servers and overlays. That way we can keep the current PORTDIR_OVERLAY syntax (the variable is also used by several external tools) and support emerge --sync bla where bla is an identifier for the overlay-server relation.
I'd greatly prefer a config file residing in /etc/portage/overlays The format being something like this: </path/to/overlay/basedir> <LOCAL|SERVER_URI> [option1=value1] Or something to that effect... The first two fields being required... The 3rd field being something that might become useful later. Make sure that there is no special-case syntax -- aim for extendable without breaking "older" code.
Nick: see the emerge patch on #35535, that's how you'd like it ?
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Sorry for the bugspam
*** This bug has been marked as a duplicate of 56485 ***
