[Koha-devel] externalising translator and etc

LAURENT Henri-Damien laurenthdl at alinto.com
Mon Nov 15 10:16:11 CET 2010


Le 14/11/2010 22:51, Galen Charlton a écrit :
> Hi,
> 
> On Sun, Nov 14, 2010 at 11:48 AM, LAURENT Henri-Damien
> <henridamien.laurent at biblibre.com> wrote:
>> My idea for that is that tracking addition of zebra indexes and all that
>> stuff would be considerably eased if there was an initial etc repository
>> that installer clone into /home/koha/kohadev
> 


> Since adding a Zebra index is sometimes paired with an update to
> template files, splitting the configuration into a separate repository
> would actually make it more difficult to track Zebra updates.
I consider this as a design flaw, could be overcome with work and
collaboration on a better abstraction for lists of indexes.
(It is already work in progress for Solr. Could be quite long to
implement with zebra, but achievable, but it would only be a matter of
parsing the ccl.properties file and proposing an interface for better
management)

> It gets
> worse if you consider changes such as adding or modifying an
> authentication module, for which the default configuration changes are
> almost invariably associated with code changes.
Same for authentication. I consider this as a design flaw.
We should split authentication and identification.
And manage identification in a modular way... So that administrators
would just have to edit configuration files in order to make correct
mappings, and not dive into the code, change and commit (if they know
git enough...)

>  What you're proposing
> would make it more difficult to cleanly manage Koha development that
> touches the default configuration files; among other problems, Git's
> submodule support is such that it would require that users and
> developers would have to do more than a simple git pull or git
> fetch/rebase in order to ensure that they've fetched updates both to
> Koha and to its configuration files.
Well changing to git was already making things kind of a little bit hard
for non git users. Change was good and now everybody is using it (at
least we are even proposing ppl)
Clear and documented information would overcome this fact.

> 
>> We create a git repository for all the installations, but when you
>> create the repository from the processed files, it looses
>> synchronization with all the common indexes which could be required for
>> Koha when one adds some other minor feature or fixes a bug in the indexer.
> 
> Since it sounds like you're using dev-mode deployments for your
> customers, you (i.e., BibLibre, not necessarily you personally) could
> just as readily keep track of local customizations in the git clone
> for each installation you run, then do a make update_zebra_conf.  I'm
> sure that there are a variety of ways to script that, and perhaps some
> patches to Makefile.PL would help you better than splitting out etc
> into a submodule.
> 
>> An other reason is that etc doesnot vary much. But when it varies, when
>> you upgrade users should be aware that they might loose their custom
>> indexes. I wanted to make next upgrades smoother for libraries.
> 
> My suggestion immediately above should help you, but I also want to
> point out that make upgrade *does* create backups of any files it
> touches, so local changes are preserved that way.
Nice.

> I am not suggesting that there aren't things that could be done to
> make things easier for anybody who runs a lot of dev-mode Koha
> installations, but sticking etc off into a submodule is not the
> solution.
Well it was a proposal.

> 
>> I am with you when you propose to use different directories. This would
>> bring to :
>> etc
That organisation was the big picture, what I would envision for long
term. I didnot mean that would have to be done right away.

>>  |- koha-conf.xml or koha-conf.yml i.e. ONLY Koha common configuration
>> (database access and so on. No more zebra stuff in that. )
> 
> I would support that.  It's mostly a historical accident that
> koha-conf.xml currently serves as both the main configuration file for
> Koha and the top-level config file for zebrasrv, but there's no reason
> why those two configuration functions couldn't be placed in separate
> files.
> 
>>  |- authentication
>>  ||- LDAP
>>  ||- CAS
>>  |-webserver
>>  ||- apache2
>>  ||- nginx
>>  |- searchengine
>>  ||-zebradb
>>  ||-solr
>>  ||-pazpar2
> 
> I'm OK with splitting the configuration files.
> 

>> But then, when one chooses one type of webserver, one type of
>> authentication, one type of searchengine, he would use only a few of all
>> the installation files (which could become quite a forest).
>> I wanted the structure for etc simpler so that sysadmins would not be
>> overwhelmed by big picture.
> 
> But all of the options have to exist *somewhere*, and it would be
> simpler to manage the development of the various options if the
> configuration files and directories were all laid out directly in the
> Git repository, not relegated to topic branches.  Furthermore, if all
> of the possible configuration files are available in a production
> installation, it would be easier for a sysadmin to (say) switch from
> Apache to nginx.
Why not... But then, you would have to make dependencies quite
thorough... Or optional. debconf would surely be quite handy for that.
But would need some clarifications.

> 
> In other words, I think it is better to organize the configuration
> files well (and document them!) than to effectively atomize the
> management of them during Koha development by having permanent topic
> branches for various configuration modes.
> 
>>> 0 for moving the PO files to a separate Git project.  The size of the
>>> repository doesn't really strike me as a big deal; the Git protocol is
>>> pretty efficient.  That said, while I don't see a great deal of
>>> benefit to splitting the translations off into a separate repository,
>>> I don't see much harm either.
> 
> As I said, I don't have an strong opinion either way -- that's what
> the 0 means -- but I do think there are a couple misconceptions to
> clear up:
> 
>> Well it is quite striking when you get 249Mo to dl when doing a git
>> clone. :)
> 
> Not sure where you're getting 249M from -- it's more like 151 MiB when
> I measured today.
> 
>> (mainly because any change you commit on po files is storing a
>> new instance of this file)
> 
> Actually, no, it doesn't.  Git is better designed than that; generally
> what it would do if you commit a change to a PO file is store just the
> delta.  git gc is run on the public repo every week.  When you push or
> pull to a repository, Git transfers just compressed deltas.


More information about the Koha-devel mailing list