> Thanks for the explanation. What happens is that at least Cal/CardDAV > compile and work well without libchardet (at least under normal > circumstances) and, as it was not marked as required, I thought it's an > optional lib and here is the question of why to use it.
Actually, the same happens with transfig, libsrs2 and shapelib. The page mentiones these libs, but "Required for `make check`" (not sure what that means in relation to the lib being reqiured for cyrus-imapd as such) for all of them is "no". What would help is a column "required" yes/no and another column "usage in cyrus-imapd" explaining for what exactly it's used. Say if it's for tzdata processing in the TZDist module, then I probably won't build with it as I don't see much use for it (or maybe package it as a flavor). But if it's something essential for a broader functionality like CalDAV itself, then definitely it would be included. But at this moment the Compiling page doesn't provide these details and here we are. On 5/6/20 05:30, Anatoli wrote: > Ellie, > >> libchardet is already listed on the compiling page as being used by >> the CalDAV, CardDAV, and/or JMAP features. You would decide to >> install libchardet based on whether you need these features: if you >> don't enable these features, you don't need it; if you do, you >> probably do. >> >> If you don't have libchardet, Cyrus will not do character-set >> detection. If some piece of data has no character set coming in, it >> will have no character set. I don't know why you would decide to not >> use this, and it may simply become a mandatory requirement for these >> features in 3.4. It might have been mandatory in 3.2, if this had >> been brought to our attention during the nearly 3 month beta window; >> but now that it's in a stable release, it will remain as it is. > > Thanks for the explanation. What happens is that at least Cal/CardDAV > compile and work well without libchardet (at least under normal > circumstances) and, as it was not marked as required, I thought it's an > optional lib and here is the question of why to use it. > > I guess what you could do for 3.2 is to include a warning in configure > explaining the issue, so the maintainers see it and take appropriate > action. I suppose there are not that many installations with 3.2 yet so > if the warning is included with 3.2.2 it would be an appropriate time. > > Regards, > Anatoli > > On 4/6/20 21:58, ellie timoney wrote: >> On Thu, Jun 4, 2020, at 12:52 PM, Anatoli wrote: >>>> chardet is used by the JMAP module of httpd to detect the character >>> set of untagged 8-bit headers. >>> >>> Does that mean that these libs are required? If not, what would happen >>> if not included? How Cyrus would detect the charset? Or put in other >>> words, if they are not required, what's the benefit to use them? >>> >>> On the other hand, may I suggest to please add these details to the >>> Compiling [1] page? There's already a lot of useful information, but >>> some of the libs lack any details on what's their purpose in Cyrus and >>> why they are beneficial/required (and if they are not used yet, maybe >>> they shouldn't be mentioned there at all?). This could help porters and >>> maintainers to make more educated decisions on how to package Cyrus. >> >> libchardet is already listed on the compiling page as being used by the >> CalDAV, CardDAV, and/or JMAP features. You would decide to install >> libchardet based on whether you need these features: if you don't enable >> these features, you don't need it; if you do, you probably do. >> >> If you don't have libchardet, Cyrus will not do character-set detection. If >> some piece of data has no character set coming in, it will have no character >> set. I don't know why you would decide to not use this, and it may simply >> become a mandatory requirement for these features in 3.4. It might have >> been mandatory in 3.2, if this had been brought to our attention during the >> nearly 3 month beta window; but now that it's in a stable release, it will >> remain as it is. >> >> cld2 was used by one (or maybe both) of the experimental search features >> that were accidentally included in 3.2.0, and removed in 3.2.1 (see the >> release notes). Looks like we forgot to remove the configure checks for the >> library when removing the feature(s) that used it. You don't need it, and >> if you have it, it won't be used anyway. >> >> Cheers, >> >> ellie >>
