Re: [Koha-devel] Debian Packaging

[Alex King]

OK,

I'm just posting a quick update regarding Debian packaging.

Let's keep all the discussion on address@hidden for now, I think 
it is appropriate at this early stage.  Please subscribe there if you 
aren't yet.  If we get too noisy for that list, we can move to another 
list when needed.

I think Joshua's idea of pulling 2.2.6 (from CVS?) is probably the right 
one to start with.

I think we should maintain our own repository.  I think it makes sense 
to keep the Debian packaging stuff somewhere separate from the main code 
and merge back whatever work makes sense to the main repository.  I've 
always wanted to try out bzr and I've created my own bzr repository of 
2.2.5 (not published atm).  Meanwhile, Geoff Crompton has submitted an 
alioth project request.  What do people think?  I'm happy to use alioth, 
and happy that Geoff's taken the initiative to organise it.  Geoff, what 
is the status of the project application?

Meanwhile, MJ Ray has suggested: "

I think there's a package called something
like dpkg-cpan which we should use to package the modules (with names
like libperl-marc-record) and then bend the main koha system to do
an auto-install into debian/tmp."


(Just to clarify, are you talking about modules external to koha that 
need to be pulled from CPAN or are you talking about parts of koha which 
could be modularised?  I guess you are talking about external 
dependencies.  When I installed Koha 2.2.5 on debian testing my recall 
is that I didn't need to pull anything from CPAN, everything needed was 
already in Debian.  eg. there is a libmarc-record-perl package already 
in standard Debian.  My recall could be wrong, I might have pulled some 
stuff from CPAN)

MJ Ray also suggests:

appoint our debian-perl advisor (someone who subs to that
mailing list, relays questions and/or points out where we're getting
the perl policy wrong).

Anyone volunteering?  Who's already on debian-perl?  If there is already 
more than one of us who follow or are willing to follow that list that 
would be good.

And then the main task is to actually produce a package.  From my point 
of view the main task is hacking on the install script to get it to 
install the package to an arbitrary location (so it can be easily 
packaged).  If anyone wants to give this a go feel free.  Also making 
sure we ultimately install to FHS compliant locations.  I'm comfortable 
with doing the actual packaging once the install script can install to 
an arbitrary temp location.

I'll probably give it a go in the weekend if no-one else does before 
then.  I'm showing my ignorance here, but two things would help me.  1. 
pointer to a good resource on "learning perl in 24 hours" (I do C, 
python, shell, awk etc, but never learned perl).  2. A very quick high 
level overview of what the install script actually does (or a pointer to 
documentaion).

Thanks everyone for your help,

Alex

Joshua Ferraro wrote:
> I think 2.2.6 would be a better choice as there are quite a bug fixes
> and functional improvements.
>
> I'm all for modifying the perl code to make it more cpan-ish
>   
> ...
> Lets keep this discussion on the main list for now.
>
> Kudos for getting serious.
>
> Cheers,
>
>