Jyri Virkki wrote:
> Amanda Waite wrote:
>
>>> Define it this way instead MYSQL_PATH=/usr/mysql and
>>> MYSQL_LIB=$(MYSQL_PATH)/lib/mysql
>>>
>> I think this would lead to some ambiguity and potential problems. What
>> if you were to update MySQL to 5.2?. I might no longer be able to
>> predict if Lighttpd will be linked against MySQL 5.1 or MySQL 5.2, it
>> would all depend on the order that the two MySQL's were built. I think
>> that being specific is better.
>>
>
> It won't be ambiguous, the 'latest' link is always the latest one.
>
> Whether you want the 'latest' or a specific version depends on what
> the dependencies are.
>
> In theory, if you are depending on MySQL interfaces which are
> classified Uncommitted or better, you can know there will not be an
> incompatible change as MySQL goes from 5.1 to 5.2 (for instance), so
> you're better off depending on 'latest'. If you're depending on
> Volatile interfaces specific to 5.1 then you need to hardcode 5.1. Of
> course, if that is the case then there will be a problem eventually
> when 5.1 is removed.
>
> In practice the build already has other hardcoded areas which need to
> be changed manually as MySQL version upgrades (pkg deps, build
> component deps). Just wanted to make sure you're deciding to hardcode
> 5.1 use for the right reasons.
>
>
>
Ok, I'll work on the basis that there is only one version of MySQL on
the system and that is the one in /usr/mysql ($(ROOT)/usr/mysql in the
proto area). If at some point lighttpd breaks either build wise or
functionality wise because of a change to the version of MySQL then
we'll treat it the same as we would if an update to say OpenSSL caused a
similar issue.
One thing though (and I maybe way off base about this), in the proto
area, how is it guaranteed that the links point to 5.1 and not to 5.0?
There is no build order dependency defined in usr/src/cmd/Makefile and
if MySQL 5.0 is built after 5.1 then the links point to 5.0. At the
moment it's possible that 5.0 gets built before 5.1 because other
components have a dependency on 5.0. This won't be the case once
everything depends on 5.1. This bothered me when Sunanda first
mentioned it, it bothers me more now that when I ran nightly builds
yesterday I saw the following:
Files that changed between yesterday and today:
Unit T File Name Reloc/Sym name perm owner group
inode lnk maj min package(s)
------------------------------------------------------------------------------------------------------------
filea: s usr/mysql/lib 5.0/lib 777 - -
0 1 - - proto
fileb: s usr/mysql/lib 5.1/lib 777 - -
0 1 - - proto
differ: symlink
filea: s usr/mysql/bin 5.0/bin 777 - -
0 1 - - proto
fileb: s usr/mysql/bin 5.1/bin 777 - -
0 1 - - proto
differ: symlink
filea: s usr/mysql/man 5.0/man 777 - -
0 1 - - proto
fileb: s usr/mysql/man 5.1/man 777 - -
0 1 - - proto
differ: symlink
filea: s var/mysql/data 5.0/data 777 - -
0 1 - - proto
fileb: s var/mysql/data 5.1/data 777 - -
0 1 - - proto
differ: symlink
filea: s usr/mysql/docs 5.0/docs 777 - -
0 1 - - proto
fileb: s usr/mysql/docs 5.1/docs 777 - -
0 1 - - proto
differ: symlink
filea: s usr/mysql/share 5.0/share 777 - -
0 1 - - proto
fileb: s usr/mysql/share 5.1/share 777 - -
0 1 - - proto
differ: symlink
filea: s etc/mysql/my.cnf 5.0/my.cnf 777 - -
0 1 - - proto
fileb: s etc/mysql/my.cnf 5.1/my.cnf 777 - -
0 1 - - proto
differ: symlink
filea: s usr/mysql/include 5.0/include 777 - -
0 1 - - proto
fileb: s usr/mysql/include 5.1/include 777 - -
0 1 - - proto
differ: symlink
filea: s usr/mysql/sql-bench 5.0/sql-bench 777 - -
0 1 - - proto
fileb: s usr/mysql/sql-bench 5.1/sql-bench 777 - -
0 1 - - proto
differ: symlink
filea: s usr/mysql/mysql-test 5.0/mysql-test 777 - -
0 1 - - proto
fileb: s usr/mysql/mysql-test 5.1/mysql-test 777 - -
0 1 - - proto
differ: symlink
