On Thu, Jan 2, 2014 at 2:04 PM, Joseph R. Justice <jayare...@gmail.com>wrote:
> [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 > [Had a premature message send.] where XYZZY is the version of the amalgamated SQLite shipped with that version of Fossil). Or, alternatively, if they wish they can specify a version XYZZY of SQLite which is older than the amalgamation version but still sufficiently recent (in terms of functionality and bug fixes) to provide all the capability this versioned release of Fossil requires. This way, the fossil-scm.org devs are explicitly saying "We only support this version of Fossil with the version of SQLite it was shipped with (or alternatively with versions of SQLite which are at least so old)", which is a perfectly reasonable thing for them to say, and the devs do not have to worry about supporting a given version of Fossil with any old version of SQLite which is available as a shared library (which was Dr. Hipp's complaint). Instead, they are punting the problem of making the newest version of Fossil work with older and unsupported-by-the-fossil-scm.org-devs versions of SQLite to the FOSS Unix/Linux distribution and the packagers of Fossil for that distribution, which is completely appropriate because that *is* the job of the distribution and its packagers, to take software and integrate it with the rest of the distribution (and specifically with the distribution-provided shared library version of SQLite). Now, the distribution and its packagers might resolve this by modifying the newly released version of Fossil to work with the older shared library version of SQLite (and being responsible for any bugs or user issues introduced by this, which again *is* their job); they might resolve this by saying "This new version of Fossil requires an update to the shared library SQLite, and the end user will have to update their copy of SQLite and (as necessary) any other applications depending on SQLite before they can install this new version of Fossil"; they might resolve this by choosing not to distribute the newly released version of Fossil (such that if their end-user wants to use this version they will either have to obtain a binary version elsewhere, e.g. from fossil-scm.org, or else by compiling and installing it themselves as locally-installed software). All these are things distributions routinely have to do for the software they choose to distribute, and none of them (except the last as described below) affect the fossil-scm.org devs or their work. I note that the last option of the distribution, declining to themselves ship a package the distribution is responsible for supporting for the newly released version of Fossil, such that an end-user desiring to use this newly-released version must obtain it themselves elsewhere either as a binary file (which likely they will d/l from fossil-scm.org) or as source code they (probably) obtain from fossil-scm.org and must compile, link, and install themselves, imposes a maintenance and support burden on the fossil-scm.org devs precisely because it is now the devs providing the software to the end user and not the distribution. But, this is a burden the devs have already accepted (since binary files and source code files are already provided by them), and insofar as the software is released without any warranty, etc, and insofar as the devs have already provided help and support channels (e.g. the fossil-users list, the wiki, etc), and insofar as I presume the devs would be willing to sell commercial paid-for support to any end-users willing to pay for it (probably along the same lines as the commercial support available for SQLite), I expect this would continue to be acceptable to them (well, at least as long as the existing devs and help / support channels do not become overwhelmed by an "perpetual September" mass of new users). Oh, and I'll note that I expect this *should* only be necessary for *versioned* releases of Fossil, e.g. non-tip-of-tree. I doubt there are many, or indeed any, FOSS Unix/Linux distributions which would regularly attempt to release a Fossil package based on the current Fossil tip-of-tree (they might make a defacto release based on tip-of-tree if there were a long time between versioned Fossil releases, but I do not expect this to normally be the case). So, for non-versioned releases of Fossil, the fossil-scm.org devs can do as they like, and the distributions won't care. It is only the *versioned* releases the distributions normally care about. In summary... If the fossil-scm.org devs release *versioned* releases of Fossil with code that mandates use of a specific versioned release (or at least a specific versioned release or later) of SQLite, and in particular normally the version of the versioned release amalgamation build of SQLite distributed with that version of Fossil, then there should be no reason for the fossil-scm.org devs to worry about making that version of Fossil work with an older than the specific version release of SQLite if they do not want to. The fossil-scm.org devs have done their job by indicating which version of SQLite they are willing to support using the new version of Fossil with. Instead, it becomes the problem of the various FOSS Unix/Linux distributions and their packagers of Fossil to deal with by making that new version of Fossil work with their older shared library version of SQLite, if they so choose. (Or, by mandating that their shared library version of SQLite be updated to the minimum or only version supported by the new version of Fossil before an end-user can install the new version of Fossil, or by deciding that they cannot support and therefore will not themselves package and distribute the new version of Fossil and instead will only package and support an older version of Fossil or instead no version of Fossil at all, e.g. they will stop distributing it and require end-users who desire that version (or any version) of Fossil obtain it elsewhere.) Thanks for your time. Hope this is of some use, interest. Be well. Joseph
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
