I've been thinking and sharing with some an idea I want to share with all of you. Since I stepped into Koha's world I've been focused (sometimes obsessively, I should admit) on the user POV. Specifically on the ways to deploy, maintain and finally use koha. We are now encouraging people to use the packages, and the way of using/deploying Koha has been slowly diverging from the tarball/git and packages setup. Also, the QA process itself takes both approaches appart. Think of the tarball installing DOM as default and packages not even supporting it as an example of what I mean. Think of memcached support, and so on. Once something is pushed, there has to be a 'packages version' for that: twice the work for everyone! We have reached a point at which we have a really nice set of daily maintainance tools: the koha-* scripts, and a sound install schema that supports multiple instances. Or a single default one if we built a 'koha' package that automates its creation, which I think is WIP right now. My proposal is that koha-* commands shouldn't be Debian (.deb) specific. And make the install schema used for packages the default/standard on git/tarball install. The same should happen to multiple instances setups. Both the users and devs should benefit from such a move. Thanks for your constructive comments on the subject! Regards To+ P.S. I belive this is a mid/long term discussion, I'm no way trying to make any sudden move. I just belive this is the way to have the time for a needed planification.
Hi, On Wed, Jun 26, 2013 at 7:31 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
My proposal is that koha-* commands shouldn't be Debian (.deb) specific.
I agree, there is nothing that seems inherently Debian-specific to the Koha instance and cluster management scripts. Making them available for other platforms is a worth goal.
And make the install schema used for packages the default/standard on git/tarball install. The same should happen to multiple instances setups.
I'd like to know in a little more detail what you mean by this. For example, I would be opposed to (say) mandating the package's current default of GRS-1 for bib indexing as opposed to DOM. Now if there are things that can be done to make it easier to keep the package's installation defaults in line with Makefile.PL, I'm for implementing them. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
On Wed, Jun 26, 2013 at 11:57 AM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Wed, Jun 26, 2013 at 7:31 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
My proposal is that koha-* commands shouldn't be Debian (.deb) specific.
I agree, there is nothing that seems inherently Debian-specific to the Koha instance and cluster management scripts. Making them available for other platforms is a worth goal.
And make the install schema used for packages the default/standard on git/tarball install. The same should happen to multiple instances setups.
I'd like to know in a little more detail what you mean by this. For example, I would be opposed to (say) mandating the package's current default of GRS-1 for bib indexing as opposed to DOM. Now if there are things that can be done to make it easier to keep the package's installation defaults in line with Makefile.PL, I'm for implementing them.
What I propose is fixing those standing divergences (things available in tarball installs should seaminlessly be available on packages setups) and then make Makefile.PL arrange stuff like packages do. Packages then should do nothing special about files on the filesystem (debian/rules should only link to system jquery for instance, but not much more than that). Regards To+
Hi, On Wed, Jun 26, 2013 at 8:17 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
What I propose is fixing those standing divergences (things available in tarball installs should seaminlessly be available on packages setups) and then make Makefile.PL arrange stuff like packages do. Packages then should do nothing special about files on the filesystem (debian/rules should only link to system jquery for instance, but not much more than that).
Thanks for clarifying -- this makes sense to me. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Tomas Cohen Arazi schreef op wo 26-06-2013 om 11:31 [-0300]:
My proposal is that koha-* commands shouldn't be Debian (.deb) specific.
There are a number of assumptions that the scripts make about being in a Debian-y environment, particularly how the init scripts work, location of lock files, how apache wants to be configured, and stuff like that. These aren't insurmountable, but awareness is needed. There are also some non-perl dependencies that it expects (like xmlstarlet) but these could be tested for. You'll also have to account for people moving from the current tarball style to a package-like layout, that'll cause some headaches. OK, so those are the downsides I can see, this said, I think it's still a good idea. It annoys me a lot when a patch breaks the packages, so having a closer workflow would reduce the incidence of that happening. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
On Wed, Jun 26, 2013 at 7:35 PM, Robin Sheat <robin@catalyst.net.nz> wrote:
Tomas Cohen Arazi schreef op wo 26-06-2013 om 11:31 [-0300]:
My proposal is that koha-* commands shouldn't be Debian (.deb) specific.
There are a number of assumptions that the scripts make about being in a Debian-y environment, particularly how the init scripts work, location of lock files, how apache wants to be configured, and stuff like that. These aren't insurmountable, but awareness is needed. There are also some non-perl dependencies that it expects (like xmlstarlet) but these could be tested for.
I agree, those need to be addresed. Basically RHEL/CentOS/XSuSE don't have the a2{en|dis}{mod|site} commands available.
You'll also have to account for people moving from the current tarball style to a package-like layout, that'll cause some headaches.
I agree, the move tarball > packages for meant deploying a new server for us to make the transition. OK, so those are the downsides I can see, this said, I think it's still
a good idea. It annoys me a lot when a patch breaks the packages, so having a closer workflow would reduce the incidence of that happening.
I belive everyone would benefit from such a move. With good planning and lead we can do it. Regards To+
participants (3)
-
Galen Charlton -
Robin Sheat -
Tomas Cohen Arazi