[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 28 Apr 2016 12:00:58 +0000 (UTC)
From: Claudio André <claudioandre.br@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: System wide build
Solar Designer <solar@...> writes:
>
> On Sun, Apr 24, 2016 at 04:52:17PM +0000, Claudio Andr?? wrote:
> > The excerpt below might clarify.
> >
> > + puts("System-wide exec: " "$JOHN/");
> > + puts("System-wide home: " "$JOHN/");
>
> Why do you need these two lines, and why put the "$JOHN/" in separate
> quotes? Don't these two lines always print literally this? -
>
> System-wide exec: $JOHN/
> System-wide home: $JOHN/
Well, I don't need them, but since this is a system wide build, the --
list=build-info has to print the same information another system wide build
prints, no? Extra quotes are not necessary and they will print $JOHN. I can
use path_expand("$JOHN/") in the final version (if needed).
>
> Please do think again assuming that a patch like the original one gets
> accepted into jumbo.
Of course, I can. But I think this is the worst choice. the real env var name
used in the SNAPPY changed in the past and can change again in the future.
And
1. $JOHN simply works;
2. I expected someone to complain that using an env var to build a path to
expand and select a fallback executable is a security concern. export
JOHN=/whatever/fake_john can be harmful(?).
But, as I told you, once a different thing got accepted on bleeding I can use
it.
>
> Why not just avoid having JOHN_SYSTEMWIDE_EXEC set in the snap package,
> if you need the #else code version here?
Unfortunately (I'm kidding), the SNAP package *IS* a system wide build
installed for all users in a read-only FS. So, a pure non system wide will
fail (log, pot in a read only directory).
Isn't this the 'avoid to create something new' best choice?
Claudio
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
