ekacnet - well if you look at "lib/ldb/common/ldb_msg.c" then you notice that it is exactly like that (also written in the comments). It's by design since the comparison of the attribute values is done bytewise (binary).
I would suggest to not change the LDB interface (perhaps write some wrapper directly in the "upgradeprovision" script).

Of course I can cope with it in upgradeprovision (it's already the case btw).

The question that has to be solved is how ldb_msg_diff should make the comparison between 2 attribute, either bitwise or by using attribute comparator if available.

Maybe we should keep the default behavior and have the other way as an option so that we didn't break what is already making this assumption but we allow a more logical behavior. 

I would add the other option as a new function to don't break compatibility (not only a new parameter).
But if you would like to have this changed then I would discuss it on the mailing list; especially with Simo which is the library maintainer.

Well, I close this with "WONTFIX" here and we should start some discussion on the mailing list (or write yourself a wrapper in "upgradeprovision").

Why such hurry to close this bug. 
From my point of view the bug is there: ldb_msg_diff do not use the compare function of each element to decide whether compared element are equal or not.

After I agree that changing the current behavior is not the better thing.

I reopen this bug until we have the time to discuss this, if the bug was 6 months old I could understand your will to close it. But right now, no sorry it's not the good way to my mind. As you're somehow denying the existance of the problem or reducing it just to upgradeprovision and it's clearly not a pb just for upgradeprovision.

Okay, agreed - we will track this issue here.

Idra, would you be fine for a change in the "ldb_msg_element_compare" function or in the "ldb_val_equal_exact" function (ldb_msg.c) in order to allow real value comparisons through the attribute syntax functions?
Or should we better introduce an additional function which cares about this?

idra, could you please express your opinion about a "ldb_msg_element_compare" change?

What you propose is a change in behaviour.
Before changing it, it would need extensive tests to make sure everything continues to work, especially with standalone ldb.

(In reply to comment #8)
> What you propose is a change in behaviour.
> Before changing it, it would need extensive tests to make sure everything
> continues to work, especially with standalone ldb.
> 

I would rather suggest that we agree that yes it's not the best behavior, like that but that it's maybe safer to create a second ldb_msg_diff that do use correct compare function.

Indeed, the difficult issue here is to determine if:
 - The caller wanted to know if there are case differences (so it could fix them)
or
 - The caller wanted to know if the messages had the same semantic meaning

These are two very different issues, and need different functions.  We should not change the LDB API at this fundamental level, so a 'same semantic meaning' function will need to have a different name. 

I tend to agree with Andrew here.

Ekacnet, should we still implement such comparison calls (I mean in the core LDB)?

Ekacnet, do you still want to have this bug open?

yes

Ekacnet, I find the best would be if you write such a patch or at least a proposal - so that we are able to see how you would like to have this interacting with the existing code.
I mean for example would you like to have a function comparison pointer on the "ldb_msg_element_compare" call in order to distinguish between the comparison methods? Or would you be satisfied with a bool flag which switches the comparison mode?

(In reply to comment #15)
I don't think we should change current implementation, but rather implement another one in DSDB layer. 

Ekacnet, I'm assigning this up to you.

This will only be implemented if you provide the patches I think.