| View previous topic :: View next topic |
| Author |
Message |
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1771
Location: PB, Germany
|
 Posted: Thu Jun 05, 2014 6:29 am Post subject: eix-sync fallback to webrsync |
 |
|
Hi,
is there any way to make eix-sync fall back to some emerge-delta-webrsync if rsync failed?
Or even better if it is possible to run some script or check to make some option active?
Because I have some multi connection layout on mobile devices which not always have rsync capable links I would like to check for the required link first before doing rsync, otherwise I would like to fallback to http based connection.
I could use http generally but even the great improved emerge-delta-webrsync consumes more traffic than some small rsync delta, especially when using mobile uplinks.
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jun 05, 2014 7:34 am Post subject: |
|
|
| /etc/eix-sync.conf wrote: | | -c script-which-calls-eix-sync-and/or-webrsync |
You could also play around with !! hooks to set a default value of the undocumented variable emergecmd (with Push -c emergecmd emerge --sync or another value), but the above seems cleaner to me, although it needs a separate script. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jun 05, 2014 8:36 am Post subject: |
|
|
If you just want a fallback, you can do something like
| /etc/eix-sync.conf wrote: | -c eval
-C "emerge --sync || emerge-webrsync" |
|
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1771
Location: PB, Germany
|
| Posted: Thu Jun 05, 2014 8:36 am Post subject: |
|
|
| mv wrote: | | /etc/eix-sync.conf wrote: | | -c script-which-calls-eix-sync-and/or-webrsync |
|
I guess you meant
| /etc/eix-sync.conf wrote: | | -c script-which-calls-emerge--sync-and/or-webrsync |
Or do you mean eix-sync will call eix-sync recursively?
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jun 05, 2014 8:38 am Post subject: |
|
|
| Massimo B. wrote: | I guess you meant
| /etc/eix-sync.conf wrote: | | -c script-which-calls-emerge--sync-and/or-webrsync |
|
Yes, thanks. Of course, I meant this.
(Please do not overlook the posting before - apparently we posted simultaneously.) |
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1771
Location: PB, Germany
|
| Posted: Thu Jun 05, 2014 8:44 am Post subject: |
|
|
If I can check safely for a working link, I would prefer this over emerge --sync || webrsync. A simple check could be | Code: | | ip link ls |grep mobile0 |
...if not checking for a real successful connection to rsync mirror.
I guess I go for -c Option and do my own checking and syncing, maybe also doing the Overlay syncs there because that also depends if I get git:// connection over the available links. So I keep eix-sync only for updating eix itself at the end...
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jun 05, 2014 9:32 am Post subject: |
|
|
| Massimo B. wrote: | | So I keep eix-sync only for updating eix itself at the end... |
If you also put your own code for generating metadata for the synced overlays into your script, and if you do not plan to fetch data for eix-remote, it is probably simpler if you do not call eix-sync at all but just "manually" copy the database to the backup location before syncing and call eix-update and eix-diff at the end of your script.
Then your script does practically the same than eix-sync (for your situation) and you do not have to deal with the complexity of the latter... I guess it will not do much harm if e.g. in the rare cases when eix gets updated to an incompatible version your eix-diff fails (eix-sync has some code to handle such situations gracefully by calling eix-update twice). |
|
| Back to top |
|
|
Massimo B.
Veteran
Joined: 09 Feb 2005
Posts: 1771
Location: PB, Germany
|
| Posted: Thu Jun 05, 2014 11:00 am Post subject: OFT: eix-remote replacing emerge --sync? |
|
|
btw. today I got to know eix-remote which on first look I thought I wouldn't need. With some help on #gentoo.de (thanks thomasg) I got to know the very simple eix-remote update and added | Code: | KEEP_VIRTUALS=true
REMOTE_DEFAULT=1 |
to eixrc. Now I'm able to look into all those overlay without synchronizing them. That I always looked for...
But that makes me think about why not dropping the huge portage ball at all? You created eix which is very complete today because emerge --search was never performant and flexible (I'm sure you would even write a better portage beside the existing approaches...).
Now knowing eix-remote, why should one have the whole portage with files cached locally, including files I never need, not only ebuilds. I often thought about why those meta files are synchronized with portage and not later at emerge. Since eix-remote could give information about any existing package why not synchronizing the required portage tree parts only when required and dropping emerge --sync completely? That could already work with existing portage since /etc/portage/rsync_excludes also works.
_________________
HP ZBook Power 15.6" G8 i7-11800H|HP EliteDesk 800G1 i7-4790|HP Compaq Pro 6300 i7-3770 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jun 05, 2014 3:54 pm Post subject: Re: OFT: eix-remote replacing emerge --sync? |
|
|
This is now a different topic, but do you really want to see all overlays at every query of eix? That's why eix-sync/eix-remote/eix has some code to maintain a database with the portage tree alone and a secondary database with overlay data "merged" (actually two such secondary databases, since there is different overlay data maintained on gentoo and zugaina servers), and you can switch between these two with "-R" or "-Z".
| Massimo B. wrote: | | why not dropping the huge portage ball at all? |
The least thing portage would need is the full content of the metadata/ subdirectories.
The eix database does not contain the full content of these directories; for instance, only the description string of the most current version of each package are stored, no URL addresses are stored, {R,P,}DEPEND is only stored when DEPS=true etc.
It would not be a big issue to rewrite portage such that only the metadata/ subdirectory need to be synced, and the rest only at emerge time.
| Quote: | | why should one have the whole portage with files cached locally, including files I never need |
It is a nightmare when you want to update a system which is not online: You would manually need to download all those tiny files and put them on the right place. Currently, you only have to put the actual tarballs into $DISTDIR, manually. |
|
| Back to top |
|
|
|
Portage & Programming
