On Sat, Jan 4, 2014 at 11:04 AM, Richard Hipp <d...@sqlite.org> wrote:
> On Sat, Jan 4, 2014 at 10:59 AM, Joseph R. Justice <jayare...@gmail.com>wrote: > >> On Fri, Jan 3, 2014 at 9:28 PM, Richard Hipp <d...@sqlite.org> wrote: >> > > OK, so I propose the following fix: >>> >> >> [...] >> >> >>> (2) Remove the --disable-internal-sqlite option on trunk. Require the >>> use of the built-in SQLite only, since SQLite needs to be built with >>> non-standard compile-time options to fully meet the needs of Fossil. >>> >> >> [...] >> >> >>> (4) When distributions complain, we simply explain that we tried using >>> an external SQLite but it introduced too many complications and bugs and >>> that we now require statically linking SQLite for reasons of security and >>> reliability. >>> >> >> Just to make sure I understand... You intend to eliminate the capability >> of --disable-internal-sqlite for Fossil not only for tip-of-trunk of >> Fossil, and not only for development snapshots (although you don't really >> have that, do you?), but *also* for future *release* versions of Fossil as >> well. Correct? >> >> In other words, on http://www.fossil-scm.org/download.html , if and when >> there is a "Version 1.28" (and also for later versions beyond that one), >> the distributed source code for that version (or later) of Fossil will no >> longer support --disable-internal-sqlite, and any distribution wishing to >> package that version of Fossil such that it will use their system-provided >> shared library version of SQLite (which presumably will or at least may be >> different from the version provided with Fossil as an embedded code copy) >> will be entirely on their own to implement that capability. >> >> And further, presumably, the fossil-scm.org devs will not accept patches >> from external contributors (such as distribution packagers of Fossil) to be >> applied to the source code for the released version of Fossil to re-add >> this capability. >> > > That is my proposal, yes. > > The rational is that --disable-internal-sqlite adds no new capabilities to > the program, but it does add complexity and risk. > Okay. I intend (from the perspective of an interested bystander both of fossil-scm and of Unix/Linux distributions, wishing them to cooperate and coexist as happily as possible), to contact the package maintainers of Fossil within the various "major" Unix/Linux distributions (for some definition of the word "major", for distributions which provide Fossil as part of their distribution *and* which "actively" package it (as opposed to just using some other distribution's package without changes), and where I can identify and contact the applicable package maintainer), to inform them of this proposed change to future release versions of Fossil, and to encourage them to comment here on this list if they wish to speak up concerning this proposal before it is implemented by the fossil-scm devs. I will also encourage them to subscribe to this list if they have not yet done so, so that they can do a better job of representing their distribution to the fossil-scm.org devs (who are the upstream for Fossil). I will notify this list of the distributions and package maintainers I contact (and of any distributions which should be contacted but where I cannot manage to identify or contact the maintainer). At a minimum, I expect/hope to contact the applicable packager for the following distributions (subject to their packaging Fossil as part of the distribution; if they do not, there is no reason for me to contact them): (1) Debian (Ubuntu derived from Debian and has the same maintainer, Linux Mint derived from Ubuntu and/or Debian may use the same package, many others derived from Debian and/or Ubuntu) (2) Fedora (CentOS and Scientific derived from RHEL which is largely derived from Fedora, note that Fedora provides EPEL which is Fedora packages compiled for RHEL, CentOS, Scientific; might be good to contact CentOS and Scientific anyway) (3) openSUSE () (4) Gentoo (Sabayon derived from Gentoo) (5) Slackware () (6, 7, 8) The BSDs: FreeBSD, NetBSD, OpenBSD (NOTE: The packager for Fossil for OpenBSD is already a participant in this discussion and does not need to be contacted!) (9, 10) The Solaris variants: OpenIndiana, SmartOS I may also contact: Arch (Manjaro derived from Arch), Mageia (), Puppy (), DragonFly BSD, GhostBSD, MidnightBSD, PC-BSD (all these BSDs derived from FreeBSD), but will not worry about them as much as the 10 I've identified above. Proposed message, *please* comment if you disagree with any of it or wish me to add any information, I will not send this message before the evening (East Coast USA time) of Tues, 7 Jan 2014 (possibly later if it takes me longer to identify a maintainer): ========== Hello. I am an interested bystander of the Fossil SCM project (www.fossil-scm.org). I am *not* a developer within this project, nor do I have any other authority or responsibility within it than any random bystander and member of the peanut gallery might have. I have identified you as the person within $DISTRIBUTION who takes responsibility for packaging and maintaining Fossil for this distribution. Recently, the developers of Fossil have proposed removing the capability of compiling Fossil such that it can use the instance of the SQLite database library provided by the distribution as a shared system library. (Specifically, they intend to eliminate the compilation flag "--disable-internal-sqlite".) They intend to do this because they believe it will benefit them as the developers of Fossil; they believe it is unnecessary and indeed actively disadvantageous / undesirable for the development and support of Fossil that they provide this capability. Instead, they intend to only provide source code for Fossil that is capable of using the embedded source code copy of SQLite provided as part of the Fossil source code distribution. They do not intend to support Fossil's being able to be compiled to use a shared system library version of SQLite, and will not accept patches to re-add this support into the upstream copy of Fossil, either the development version or any release version. This change will affect release versions of Fossil starting with version 1.28, when and if that version is tagged and released. It will not affect the current release version of Fossil, 1.27, nor will it affect earlier release versions of Fossil. The change will also affect development (non-release) versions of Fossil starting at some point in the development between release versions 1.27 and 1.28. I believe this may affect you (as the packager of Fossil for $DISTRIBUTION), and/or Fossil's status within $DISTRIBUTION, for release versions starting with 1.28. Note that this change is *not* yet finalized, although influential developers within Fossil upstream (most notably the architect of Fossil) wish strongly to make this change. If you desire to provide feedback (either positive or negative) concerning this change before it is implemented, how it will affect you as the packager of Fossil for $DISTRIBUTION, and/or how it will affect Fossil's status within $DISTRIBUTION starting with version 1.28 of Fossil, I encourage you to contact Fossil upstream via the fossil-users mailing list Real Soon Now. If you do not, then this change will be made even if you think it is an undesirable one from your perspective or the perspective of $DISTRIBUTION. (It may be made *even if* you contact upstream to advocate against it, but it certainly will be made if you do not.) Assuming you continue to intend as the responsible packager of Fossil for $DISTRIBUTION, I would also suggest that you subscribe to the fossil-users list if you do not yet do so. This is the primary means that Fossil upstream uses to communicate proposed changes to Fossil that might affect you and/or $DISTRIBUTION. Information about the fossil-users mailing list and how to post to and/or subscribe to it can be found at http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users . Information about this proposed change can be found in the mailing list archives for fossil-users, including and most specifically: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14181.html(start of thread); http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14184.html(initial proposal to remove --disable-internal-sqlite); http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14194.html(asking for confirmation that this change will affect release versions starting with 1.28 and that third party patches to re-add this support to Fossil upstream will not be accepted); http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14195.html(confirmation that this will indeed be the case). Note: if you intend to communicate feedback to Fossil upstream concerning this proposed change to Fossil, *do* *not* send it to me, I can do nothing useful with it. Instead, send it directly to the fossil-users mailing list. (You may CC me if you really feel the need to, but I am subscribed to fossil-users and will see any message you send there. Remember also that I am in no way involved with the development of Fossil, so my opinion on this matter carries little or no weight.) Note also that Fossil upstream, via the fossil-users list, is aware that I have sent this message to you (because I sought their feedback on it before sending it) but was in no position to affect my sending it; if you object to receiving it, it is solely my responsibility and not theirs in any way whatsoever. Thanks for giving me some of your time. I hope you have found this of some use and interest. Sincerely, Joseph R. Justice ========== I would also *like* to suggest to LWN.net that they cover this proposed change, at least as a side-note story, because I think it is of potential interest to them. I suppose the easiest way would be to send them a copy of the message I propose sending above (with any applicable changes as suggested here), with an appropriate preface. Do you have any objection to my sending LWN a message suggesting that they investigate this discussion, and possibly make note of it in the next issue of LWN? (Note that they might run across this discussion even if I do not contact them, so my not contacting them does not insure they will not become aware of it, tho it probably significantly lessens the likelihood of it.) Thanks for your time. I hope this is of some use, interest. Joseph PS: On the off chance it is of interest... I got the set of Unix/Linux distributions I propose to contact concerning this in part from the following information: DistroWatch.com "Major Distributions" ( http://distrowatch.com/dwres.php?resource=major): Linux Mint, Ubuntu, Fedora, Debian, openSUSE, Arch, PCLinuxOS, CentOS, Mageia, Slackware, FreeBSD DistroWatch top 20 "Most Popular Distributions based on Page Hit Ranking for the last 12 months" ( http://distrowatch.com/dwres.php?resource=popularity): Mint, Ubuntu, Debian, Fedora, openSUSE, PCLinuxOS, Manjaro, Arch, Puppy, CentOS, Zorin, CrunchBang, FreeBSD, Bodhi, Lubuntu, Slackware, elementary, SparkyLinux, Sabayon DistroWatch top 10 "Independent Distributions" (based on P.H.R. for last 12 months) ( http://distrowatch.com/search.php?ostype=All&category=All&origin=All&basedon=Independent¬basedon=None&desktop=All&architecture=All&status=Active): Debian, Mageia, Fedora, openSUSE, PCLinuxOS, Arch, Puppy, FreeBSD, Slackware, Gentoo DistroWatch selected BSD-type distributions ( http://distrowatch.com/search.php?ostype=BSD&category=All&origin=All&basedon=All¬basedon=None&desktop=All&architecture=All&status=Active): FreeBSD (DragonFly BSD, GhostBSD, MidnightBSD, PC-BSD), NetBSD, OpenBSD (MirOS) DistroWatch selected Solaris-type distributions: ( http://distrowatch.com/search.php?ostype=Solaris&category=All&origin=All&basedon=All¬basedon=None&desktop=All&architecture=All&status=Active): OpenIndiana, SmartOS
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
