Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72190 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 65986 invoked from network); 4 Feb 2014 10:58:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2014 10:58:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:58312] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 49/00-64896-3C7C0F25 for ; Tue, 04 Feb 2014 05:58:12 -0500 Received: (qmail 28367 invoked by uid 89); 4 Feb 2014 10:58:08 -0000 Received: by simscan 1.3.1 ppid: 28361, pid: 28364, t: 0.0640s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 4 Feb 2014 10:58:08 -0000 Message-ID: <52F0C86A.9010805@lsces.co.uk> Date: Tue, 04 Feb 2014 11:00:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: PHP Developers Mailing List Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Modular distributions From: lester@lsces.co.uk (Lester Caine) While at least part of the answer is 'it's not our problem', in general Linux distributions provide a modular approach to managing installations. The various comments about version numbers prompts me to remember the hassle that was incurred when I tried to switch distributions because there is no standard way of handling this. I'd like to float the idea of providing a standardised way of handling a more modular approach to handling this for PHP6. The main part relates to breaking down the ever expanding central .ini file so that each extension has it's own ini file as is done by the distributions I'm currently using. Moving on from this is adding the ability to update a single module, such as the timezone data, where an external update can be more easily applied between releases. I'm actually looking at the problems of maintaining PHP5.3 when it gets EOL and which 5.2 currently has in relation to timezone data. 'Not our problem' I know, but providing the right tools would reduce workload if third parties can more easily take over that work. The main focus here though is to more easily allow 'development' versions of extension improvements to be used in the field, rather than having a fully bundled update? In the past maintaining the windows installations has been by just updating a single extension, and formalising that still makes sense to me although I know that many of you prefer the 'core bundle' model which includes many packages that never actually get used by some of us. A modular model is used by the Linux distributions and seems to be preferred anyway? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk