[Top-posting considered harmful. *cough*] On Thu, Jan 2, 2014 at 12:40 PM, B Harder <brad.har...@gmail.com> wrote: > On 1/2/14, Richard Hipp <d...@sqlite.org> wrote:
>> The silly requirement of some distributions that *everything* must be a >> shared library irks me beyond words. I hate having to support >> --disable-internal-sqlite, and I hate having to add silly work-arounds in >> the code to accommodate distributions trying to use an older SQLite with a >> newer Fossil. This impedes progress and introduces bugs. It's a lose-lose >> situation. And yet the distributions are dogmatic on this point. >> >> It's maddening. It makes my hair turn gray. It irks me more than seeing >> the noun "data" used as a plural. Utter madness! >> >> But we live in a fallen world. We have to do it. Please go ahead and >> merge..... > > _WHY_ does --disable-internal-sqlite (and the unknown versions of > SQLite that follow) have to be supported ? > > If package/OS maintainers insist on hacking in alien shared-lib > SQLite, let them own their hacks and the repercussions. > > Call it a major version# bump, and remove that support. > I never did research this for y'all. "I should do that..." Again... My understanding, as an external observer of some FOSS Linux/Unix distributions (primarily / especially Debian), e.g. *not* as someone currently actively involved in maintaining a distribution, packaging software for it, etc, is that distributions want to minimize the number of different and distinct source-code copies of a given chunk of software (a library for instance) found amongst all the pieces of software they distribute. They want to minimize the number of source-code copies to make it easier for them to maintain all the different software packages in the distribution, by insuring that if a given piece of software needs to change (say to update it to a new version to provide new functionality, or to patch a bug (especially a security-related bug!) in an existing version that causes the software or something depending on / using the software to malfunction), they (ideally at least) only have to change the software in one place, and then update as necessary any and all other software depending on the newly-changed software to use that newly-changed version. (If the newly-changed software maintains the same ABI as the previous version of it, this might require no changes at all, or at most a change in the packaging meta-information; if there is an ABI change but the API stays the same this will probably require a re-compilation and re-linking; if there is an API change this might require changes to the source code of the other software to accommodate the API changes.) One way they minimize the number of source-code copies of software, particularly of software that is used by other software (e.g. such as a library like SQLite), is to require the shared software to be linked in as a shared (e.g. not a binary or source-code embedded) library to all the other software making use of it. I think that, if I were ever to do the required research (which, again, I have not done to date), I would find that most major FOSS Linux/Unix distributions, and quite likely many of the commercial / closed-source distributions (I speak here not merely of RHEL, SUSE, etc but also of Solaris, HP-UX, AIX, etc), are ... I won't say dogmatic about this point, but quite serious at the least about it, precisely because it makes their lives easier and because they see it as a benefit to their end-users. I think it is not a point they would give up lightly. I realize this is likely to be a quite different viewpoint / world view than those coming from the embedded software world or from the MS Windows (and probably also Apple OS/X) world have, and I suspect also commercial / closed-source software provided for various FOSS and non-FOSS Unix/Linux distributions, because in those worlds it is common for every piece of application software to ship its own private copy of any library it requires (other than libraries which can be guaranteed to be provided by the OS vendor). Further, in the embedded software world at least, I expect it is often difficult or even impossible to update software in the first place to patch bugs or provide new functionality, so there is no need much less desire to worry about making it *easier* to update software; if you can't update it at all, or can only update it in the first place with the very greatest of effort for only the most critical of reasons (such as bugs which are potentially life-threatening or would cost untenable financial losses if they are not fixed), who cares if it's a only a little more difficult, relatively speaking, to update a library. Anyway. Insofar as SQLite intends and desires to be capable of use as a shared non-embedded library *as well as* a non-shared embedded library for software running on Unix/Linux platforms, I expect this policy (as I've asserted it to be) of the FOSS Unix/Linux distributions will affect SQLite and application software making use of SQLite such as Fossil. If Fossil removes support for using SQLite as a shared library, I expect the distributions will either (1) re-add that support to the version of Fossil they package (with potentially each major/non-derivative distribution doing it a separate way); (2) fork Fossil (again, with potentially each major/non-derivative distribution doing it a separate way) at the point where support is removed and henceforth distribute their forked version of Fossil (possibly but not necessarily merging in patches providing updated or new features and functionality from Original Fossil); or (3) stop distributing Fossil themselves as being unsupportable by them, at which point the only source of pre-compiled binaries for end-users of Fossil on FOSS Unix/Linux distributions will likely be fossil-scm.org. (This might or might not be seen by you as desirable; I'm not in a position to speculate on that.) I'll grant that it is possible that instead (4) the distributions allow Fossil to be and treat it as a special case, but I suspect this is unlikely at best. Questions: First, does Fossil (or at least *versioned*, e.g. non-tip-of-tree releases of Fossil) use only versioned amalgamations of SQLite? Or instead are versioned releases of Fossil allowed to use whatever the current tip-of-tree, non-versioned amalgamation release of SQLite is? Second, does SQLite in its versioned-release amalgamation form provide a means for the application software using / linked to it to query the amalgamated SQLite for its internal version? If these questions are both true (e.g. versioned Fossil releases use only versioned amalgamations of SQLite, and versioned SQLite releases provide a means for the application software using it to query it for its version), then it seems to me the simplest solution would be to have each versioned Fossil release query the SQLite it is using (be it a shared library one or an amalgamated / compiled-in one) for the SQLite's version, and if that version does not match the version of the amalgamated SQLite shipped with the versioned Fossil release have the Fossil release immediately terminate with an error message of something like "Unsupported version of SQLite in use; this version of Fossil is only supported for version XYZZY of SQLite" (where
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
