For All Koha Hackers: * A new installer is in development. * The start is already in CVS. It doesn't work yet. * I've read old koha-devel posts and I've looked at other projects, so I think I see at least some of the pitfalls. * If you think I will break your code, please warn me now. * I aim to have this working well by the end of August. For Joshua: I've added myself to the 3.0 roadmap. Hope that's OK. For Installer Hackers: Following the installer meeting, I've taken a look at the ExtUtils::MakeMaker and ExtUtils::MakeMaker::Tutorial man pages, as well as some other articles and it looks like this is a reasonable way to go and it might work for koha. I think particularly interesting items on the main man page are: NAME, DISTNAME, VERSION (which are fairly obvious) PREREQS_PM (our dependencies) CONFIGURE (which might do the autodetection and Q&A if wanted) PM (what installs where) and PL_FILES (scripts that write files, perhaps autodetecting) I have started the ball rolling by adding Makefile.PL to the CVS HEAD. I have also removed some other files (Makefile Make.conf.in C4/Makefile.PL C4/MANIFEST) which seemed to be in the way. My next step is to use buildrelease and Install.pm to determine which files in the source tree belong where in the installed tree and write that into the Makefile.PL - at the moment, this will make the Makefile.PL very very big, mainly because of translated templates. I'd rather pack one set of templates and the po files, but which set? I'll do this this week, one way or another. Some other suggested/possible next steps are on a KohaInstaller roadmap at http://www.koha.org/wiki/?page=KohaInstaller - These are ideas and I don't have all the knowledge to decide whether they're possible: if you know more about one or have more ideas, please send comments to the list. If you can do one of the steps already mentioned, please do it and announce it on that page. Until the code is in CVS (or your patch is sent to this list), just hack the installer as you want. I ain't proud. Ultimately, this looks like it might remove buildrelease, installer.pl, Install.pm and possibly some other helper scripts. (What happens to koha.upgrade? An interesting question.) The payoff should be a simpler and more portable installer which is easier to package for every operating system distribution. -- MJ Ray (slef), K. Lynn, England, email see http://mjr.towers.org.uk/ http://www.ttllp.co.uk/koha/
On Mon 18 Jul, MJ Ray wrote:
For All Koha Hackers: * A new installer is in development. * The start is already in CVS. It doesn't work yet. * I've read old koha-devel posts and I've looked at other projects, so I think I see at least some of the pitfalls. * If you think I will break your code, please warn me now. * I aim to have this working well by the end of August.
Can I suggest one inprovement over the existing version (which you probably have already thought of and I think was discussed some time ago) and that is to provide some system of checking passwords. Things like the "kohadadmin" pw do not really matter since they can be changed afterwards, but entering the wrong pw for MSQL is disastrous: you have to start again, doctor the MSQL files etc. Would it be possible (1) to ask for pws to be entered twice and (2) for the MSQL pw to be checked (using msql -uroot -p or whatever) before the script is run? A less important point is that at the moment the q about "do you want to install a head branch and a printer" seems to take the answer "Yes" no matter whether the user types y or n ... (And I do not think the two should be concatenated. There must be many installations where only local printers (attached to worstations, and using CUPS not lpr) will be used, the koha computer having no printer attached.) Roger -- Roger Horne, 11 New Square, Lincoln's Inn, London WC2A 3QB http://hrothgar.co.uk/YAWS/ mailto:roger@hrothgar.co.uk
Roger Horne <roger@hrothgar.co.uk> wrote:
[...] Would it be possible (1) to ask for pws to be entered twice and (2) for the MSQL pw to be checked (using msql -uroot -p or whatever) before the script is run?
My current idea is to have the database loading as its own scripts: one to create the data and one to load it in, so the worst damage of an incorrect password would be needing to rerun the database loader. The two script approach would help people who want to use phpMyAdmin or similar tools: they just won't use the data-loading script.
A less important point is that at the moment the q about "do you want to install a head branch and a printer" seems to take the answer "Yes" no matter whether the user types y or n ... [...]
Now you mention it, that sounds broken. I'll try not to copy that problem into the new installer. -- MJ Ray (slef), K. Lynn, England, email see http://mjr.towers.org.uk/
MJ Ray a écrit : > For All Koha Hackers: > * A new installer is in development. > * The start is already in CVS. It doesn't work yet. > * I've read old koha-devel posts and I've looked at other projects, > so I think I see at least some of the pitfalls. > * If you think I will break your code, please warn me now. > * I aim to have this working well by the end of August. > > For Joshua: > I've added myself to the 3.0 roadmap. Hope that's OK. > > For Installer Hackers: > > Following the installer meeting, I've taken a look at the > ExtUtils::MakeMaker and ExtUtils::MakeMaker::Tutorial man > pages, as well as some other articles and it looks like this > is a reasonable way to go and it might work for koha. I think > particularly interesting items on the main man page are: > > NAME, DISTNAME, VERSION (which are fairly obvious) > PREREQS_PM (our dependencies) > CONFIGURE (which might do the autodetection and Q&A if wanted) > PM (what installs where) and > PL_FILES (scripts that write files, perhaps autodetecting) > > I have started the ball rolling by adding Makefile.PL to the CVS > HEAD. I have also removed some other files (Makefile Make.conf.in > C4/Makefile.PL C4/MANIFEST) which seemed to be in the way. > > My next step is to use buildrelease and Install.pm to determine > which files in the source tree belong where in the installed tree > and write that into the Makefile.PL - at the moment, this will > make the Makefile.PL very very big, mainly because of translated > templates. I'd rather pack one set of templates and the po files, > but which set? I'll do this this week, one way or another. A good solution would be to have : - only english templates in public version. - let the user choose which them he wants to install (+ default, always included) - let the user choose which language he wants to install for the themes he choose (& create the corresponding templates) I also have one request for the new installer : the possibility to choose SQL files to import during installation is very important. At the moment, it's under-used, but it's a very useful feature. For example, I have in my pockets, a sql file to setup a 100% working Koha for a small french public library. With all datas required (frameworks, borrower categories, item types, default issuing rules...) I also hope to be able to add for 2.2.4 some sample DB (one in french, one in english. JOSHUA : don't forget to send me a mysql dump of you sample DB) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
participants (3)
-
MJ Ray -
Paul POULAIN -
Roger Horne