Front page | perl.perl5.porters |
Postings from May 2013
On Tue, May 28, 2013 at 08:20:31AM +0200, H.Merijn Brand wrote: > On Tue, 28 May 2013 06:12:07 +0000, "Konovalov, Vadim (Vadim)** CTR **" > <vadim.konovalov@alcatel-lucent.com> wrote: > > but - more to the point - IMO number of obsoleted modules should be > > stripped from the core, not only CGI, nowadays these mostly are - DB > > modules such as SDBM_File AnyDBM_File etc > > I would agree with the sentiment that SDBM_File and ODBM_File are not > really state-of-the-art backends for tie-ing anymore, but they are > really different from CGI in the sense that the detection for the > libraries and include files is already well supported in Configure and > hints, and thus takes a huge burden of maintainers that might want to > keep these updated separately on CPAN. Both are not only XS, but also > need (a lot) of stuff on the system. Some systems are known for example > to have fake interfaces to these mimicked by similar interfaces. I believe in the past it's been mentioned that GDBM_File, NDBM_File and ODBM_File *not* being dual life is a pain because you can't build them after you've already installed perl. Which can matter, if you installed perl before you realised that you didn't have the development headers in place (or your upstream binary provider did not). SDBM_File does not have this problem as it has no external dependencies. AnyDBM_file *needs* to stay in the core as it's part of the implementation of dbmopen. In relation to this, previously I'd said that it would be fine if someone wanted to make GDBM_File, NDBM_File and ODBM_File dual life. No-one volunteered. This is always the case. Talk is cheap, and there is a lot of it. Nicholas ClarkThread Previous | Thread Next