On 02/22/2013 03:49 PM, Richard Purdie wrote:
> Just to be clear, I think we need to patch gconf to fix this, there is
> no good reason it shouldn't be handling the + character (unless you've
> found one I don't know about).
I didn't write GConf. I don't know the reason why they chose to declare
the following list of characters invalid:
"\t\r\n\"$&<>,+=#!()'|{}[]?~`;%\\".
I did look in the commit message and found no other explanations except
this:
"gconf/gconf-backend.c: (gconf_address_valid), (gconf_get_backend):
check the backend address doesn't contain any special characters."
Here is the entire commit:
http://git.gnome.org/browse/gconf/commit/?id=3d720f4a0c00af31c1d53fc4aa45d6d6580c433e
OK, let's say I remove '+' from that list. I agree, it doesn't look like
it would have bad consequences but what happens if, in the future, the
path contains another "invalid" character? Where do we draw the line?
> Hiding stderr is a recipe for problems in
> future and we want these postinstalls to run at build time.
There was a patchset on the ML these days that enabled postinstall
output redirection to a certain file. Why not have this activated all
the time for the native dpkg/opkg/rpm and, on request, for the target
binaries? We could inspect the logs in case some postinstalls failed to
run on host but we don't end the build since, maybe, some people would
still be fine with running those postinstalls on target.
Wouldn't this be better?
Thanks,
Laurentiu
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
