Summary: | setting SYNC variable in /etc/make.conf brokes emerge-webrsync utility | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sergey S. Starikoff <Ikonta> |
Component: | Core - Configuration | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | martin |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 373933 |
Description
Sergey S. Starikoff
2011-04-27 06:18:23 UTC
Are you arguing that emerge/emerge-webrsync should sanitise that variable's value? (In reply to comment #1) > Are you arguing that emerge/emerge-webrsync should sanitise that variable's > value? In the default configuration (SYNC variable is not set in /etc/make.conf) both emerge --sync and emerge-webrsync are operable (emerge --sync uses default mirrors). If I set in make.conf custom (local) SYNC mirror, emerge-webrsync becomes unoperable. With rather strange error message (SYNC variable set in make.conf is good and worsk fine with emerge --sync). To my mind this behaviour is incorrect. Perhaps (I'm not familiar with portage development) by sanitizing SYNC variable from make.conf. (In reply to comment #2) > If I set in make.conf custom (local) SYNC mirror, emerge-webrsync becomes > unoperable. It checks for rsync protocol: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=fa651f44178fa2d7a6e10f6ce2be7b36217022ca Are you using some other protocol for your SYNC setting? (In reply to comment #3) > Are you using some other protocol for your SYNC setting? No. I'm using Gentoo GNU/Linux. With stardart (rsync) portage tree access protocol. $ grep SYNC /etc/make.conf #SYNC="\ \ \ rsync://mirror.yandex.ru/gentoo-portage/" (commented because now I have to use emerge-webrsync) (In reply to comment #4) > #SYNC="\ \ \ rsync://mirror.yandex.ru/gentoo-portage/" Why does your SYNC variable start with "\ \ \ "? I guess that's why the emerge-webrsync code doesn't recognize that you are using the rsync protocol. (In reply to comment #5) > (In reply to comment #4) > > #SYNC="\ \ \ rsync://mirror.yandex.ru/gentoo-portage/" > > Why does your SYNC variable start with "\ \ \ "? I guess that's why the > emerge-webrsync code doesn't recognize that you are using the rsync protocol. To my mind it also seems strange :) But Handbook (mirrorselect -i -r -o >> /mnt/gentoo/etc/make.conf command) tells that it must be so. And my own experience prompts the fact. I guess it's a mirrorselect bug. You should be able to safely remove the backslashes and spaces. (In reply to comment #7) > I guess it's a mirrorselect bug. You should be able to safely remove the > backslashes and spaces. I've removed backslashes and spaces and check operability with updated make.conf. Everything works as it should. Am I to open a new bug about mirrorselect SYNC variable format? (In reply to comment #8) > Am I to open a new bug about mirrorselect SYNC variable format? Yes, please do. That "\ \ \ " seems like an obvious bug. There's no reason for it to do that. (In reply to comment #9) > (In reply to comment #8) > > Am I to open a new bug about mirrorselect SYNC variable format? > > Yes, please do. That "\ \ \ " seems like an obvious bug. There's no reason for > it to do that. While exploreing mirrorselect behaviour (bug #373195) I've find that it reproduces prefix from actual /etc/make.conf (if SYNC variable in make.conf contains prefix "\ \ \ " mirror select reproduces it, if not --- it display correct string). The issue is completely explored. The bug should be closed. But I'm nos shure about resolution (because it contains some, hope useful, improvement). Could you do it? The reason that your odd SYNC setting doesn't cause emerge --sync to fail is that the code which portage uses to parse make.conf (varexpand function) removes the backslashes. This behavior is not compatible with bash, so I'd like to fix to preserve the backslashes like bash does. It's fixed for bash compatibility in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e63823dd8358f50559fa616313cdde3ceaf104ed (In reply to comment #12) > It's fixed for bash compatibility in git: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e63823dd8358f50559fa616313cdde3ceaf104ed This is in 2.2.0_alpha42, but I'll leave this bug open until it's in an unmasked release. With the new behavior the comment in make.conf.example is false: The FEATURES variable now must not contain "\" at the end of lines. (In reply to comment #14) > With the new behavior the comment in make.conf.example is false: > The FEATURES variable now must not contain "\" at the end of lines. That's a regression, fixed in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=799c576de2afb31cea67cb2b186051bcdae29b1e (In reply to comment #15) > (In reply to comment #14) > > With the new behavior the comment in make.conf.example is false: > > The FEATURES variable now must not contain "\" at the end of lines. > > That's a regression, fixed in git now: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=799c576de2afb31cea67cb2b186051bcdae29b1e That's fixed in 2.2.0_alpha43 (bug 373703). This is fixed in 2.1.10.4. |