execute a command, which will prevent kdesvn-build from getting hung at the terminal by a
command trying to read some input:
What this entailed was:
* Preventing sudo from opening a direct connection to terminal. This was easy, as sudo has
a command line switch to do just that. Note that this won't work for other programs used
as the make-install-prefix command.
* Preventing subversion from prompting the user while still allowing the checkouts/updates
to succeed. This was harder, and could be a bit controversial.
Basically the big stumbling block for subversion is that because the SSL certificate for
svn.kde.org is unsigned (and will always be accessed at least once), subversion will
(rightly) prompt the user to see if they trust the site. But this breaks non interactive
builds (which is what kdesvn-build is for, after all). svn has a nice --non-interactive
switch but that defaults to rejecting the cert, which would make kdesvn-build useless.
So, what I've done for that is added code to install the appropriate signature file if it
is not detected prior to performing the update. This is, of course, bad for all the obvious
reasons:
1. It is choosing for the user to accept svn.kde.org (I don't consider this so bad really)
2. Should the SSL cert for svn.kde.org ever change (and still be invalid), then people
will have no way to allow svn to work without running it manually. I have a mechanism
to avoid redirecting stdin in case this happens however.
3. This is very dependant on subversion not changing file locations, signature algorithms,
etc. So, we're not future proof here.
However, I'm tired of waking up and seeing kdesvn-build still trying to compile kdelibs or
something because it wants to know if I want to change the mode of a file. Uh, thanks. So,
in it goes. I'm open to suggestions that are implementable for solving the svn thing in a
better fashion.
svn path=/trunk/KDE/kdesdk/scripts/kdesvn-build; revision=477110
Michael Pyne
6a86c5f0ef