On 07/09/10 00:42, Dan McGee wrote:
On Mon, Sep 6, 2010 at 9:34 AM, Allan McRae<[email protected]> wrote:
On 05/09/10 22:10, Allan McRae wrote:
On 04/09/10 19:16, Jürgen Hötzel wrote:
Hi Dan,
2010/9/2 Dan McGee<[email protected]>:
This does not remove the MD5 code from our codebase, but it does enable
linking against OpenSSL to get their much faster implementation if it is
available on whatever platform you are using. At configure-time, we will
default to using it if it is available, but this can be easily
changed by
using the `--with-openssl` or `--without-openssl` arguments to
configure.
What about just replacing the current MD5 implementation with the
OpenSSL implementation?
This would prevent conditional compilation and a direct OpenSSL
dependency in libalpm.
Can we do that? Openssl is BSD code.
Anyway, I have concerns... Think of an openssl upgrade. pacman is in
SyncFirst and it pulls in all its deps. If that pulls in openssl with a
soname bump, things may get interesting. I have not check, but I do not
think --as-needed saves us there.
My concern is lessened... I just did an update on a year old install and
pacman pulled in openssl for the lib* updates. I did another update and
nothing too bad happened. So this may be fine.
We already had this non-explicit dep chain anyway: pacman ->
libarchive -> openssl, or pacman -> libfetch -> openssl. Moving it up
one level shouldn't affect a whole lot.
The only thing that should break here is "everything else" on your
system. E.g. if you are prompted to upgrade pacman first because it is
in SyncFirst, and it pulls in an so-bump OpenSSL, then anything else
on your system that links that library won't work until you complete a
full -Syu. However, as I pointed out above, this was already happening
as far as I can see before.
Pulling openssl only happened on an old system when updating pacman.
The versioned dependencies used for Arch's pacman package are quite
relaxed so updating pacman would only pull new libfetch and libarchive
(and thus openssl) on a really old system. Remember the multiple
rebuilds of pacman when we were deciding if the libarchive and libfetch
dependency versioning should force it to pull in the openssl update and
it was finally decided it was best not to.
Anyway the choices are (with a openssl update)
1) update pacman + openssl followed by full update
2) full update with openssl (initial pacman update only when pacman is
out of date)
Stopping for whatever reason in the middle of 1) could be very painful.
Think of a network outage... and there is quite a scope for something
bad to happen as it is the entire second transaction, including package
download which may take some time. With 2), the pain only occurs with
stopping during the actual package install stage so is a much smaller
scope to cause issues.
Anyway, I like the whole not reinventing the wheel being done here so
overall I like the idea. It just gives me this nagging concern...
Allan
