gmane.linux.debian.devel.perl

MJ Ray | 6 Jul 09:53

Packaging a CGI with modules?

Perl sages,

What is the recommended way to package a CGI with its own modules?

This seems not very well-documented: not just for debian, but
generally.  I'm using MakeMaker because it seems to be halfway
portable.

As well as having ITP'd koha, I am an upstream developer of it.
Upstream, I am setting WriteMakefile()'s PM to move the files into
good locations - for example, I'm currently putting the CGIs in
$(INST_LIB)/koha/cgi-bin - and I intend to mv them with debian/rules
to meet policy.  Is that the best MakeMaker-definable location for
them to start in?

Also, I'm intending to use prompt() to obtain values to generate
configuration files.  Is there a slick way to get debconf to supply
prompt() answers, should I rerewrite the config file from post-inst,
or something else?

Any answers to the above or any pointers to stuff I've not found would
be very appreciated.

Thanks,
--

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct

(Continue reading)

Damyan Ivanov | 6 Jul 10:27

Re: Packaging a CGI with modules?

-=| MJ Ray, Fri, 06 Jul 2007 08:54:52 +0100 |=-

> What is the recommended way to package a CGI with its own modules?

Here's how I'd do it. This is my personal experience. Other pkg-perl
members are welcome to share theirs :)

> As well as having ITP'd koha, I am an upstream developer of it.
> Upstream, I am setting WriteMakefile()'s PM to move the files into
> good locations - for example, I'm currently putting the CGIs in
> $(INST_LIB)/koha/cgi-bin - and I intend to mv them with debian/rules
> to meet policy.  Is that the best MakeMaker-definable location for
> them to start in?

Sure. koha/cgi-bin for the CGIs, koha/lib for the modules (*.pm).

This way one would be able to "make INST_LIB=debian/tmp", right?

If there is some way to put custom path in CGIs' @INC, the IMO correct
place for the modules is /usr/share/koha/lib. If it is troublesome to
get that path in @INC, then install them in /usr/share/perl5/

> Also, I'm intending to use prompt() to obtain values to generate
> configuration files.  Is there a slick way to get debconf to supply
> prompt() answers,

I am not sure. What is prompt? At what stage of the build/install
process are these questions asked?

> should I rerewrite the config file from post-inst,

(Continue reading)

Dominic Hargreaves | 6 Jul 10:38

Re: Packaging a CGI with modules?

On Fri, Jul 06, 2007 at 11:27:04AM +0300, Damyan Ivanov wrote:
> -=| MJ Ray, Fri, 06 Jul 2007 08:54:52 +0100 |=-
> 
> > What is the recommended way to package a CGI with its own modules?
> 
> Here's how I'd do it. This is my personal experience. Other pkg-perl
> members are welcome to share theirs :)
> 
> > As well as having ITP'd koha, I am an upstream developer of it.
> > Upstream, I am setting WriteMakefile()'s PM to move the files into
> > good locations - for example, I'm currently putting the CGIs in
> > $(INST_LIB)/koha/cgi-bin - and I intend to mv them with debian/rules
> > to meet policy.  Is that the best MakeMaker-definable location for
> > them to start in?
> 
> Sure. koha/cgi-bin for the CGIs, koha/lib for the modules (*.pm).

Why not /usr/lib/cgi-bin, the designated place for CGI scripts?
(this is what I do for openguides).

> This way one would be able to "make INST_LIB=debian/tmp", right?
> 
> If there is some way to put custom path in CGIs' @INC, the IMO correct
> place for the modules is /usr/share/koha/lib. If it is troublesome to
> get that path in @INC, then install them in /usr/share/perl5/

I'm not sure I agree with this either. They are perl modules; assuming
there's no chance they will conflict with another package containing the
same modules, why should they not live in /usr/{share,lib}/perl5, the
designated place for them? (this is what I do for openguides)

(Continue reading)

MJ Ray | 6 Jul 11:09

Re: Packaging a CGI with modules?

Dominic Hargreaves <dom <at> earth.li> wrote: [...]
> Why not /usr/lib/cgi-bin, the designated place for CGI scripts?
> (this is what I do for openguides).

In short, how do you reference that from Makefile.PL using $(INST...)
and similar?

(Through $(INST...) and friends, MakeMaker also supports installations
in /usr/local and /home, and reduces the assistance required from me
for RPMs and Win32, so I'd really like to use it as a base.)

If it can't be done from Makefile.PL, I'm happy to move them there
with a mv in debian/rules.

> [modules] why should they not live in /usr/{share,lib}/perl5, the
> designated place for them? (this is what I do for openguides)

Yes, I'm pretty happy to put the modules in the usual perl paths AFAP.

Many thanks,
--

-- 
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Experienced webmaster-developers for hire http://www.ttllp.co.uk/
Also: statistician, sysadmin, online shop builder, workers co-op.
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/

Dominic Hargreaves | 6 Jul 20:32

Re: Packaging a CGI with modules?

On Fri, Jul 06, 2007 at 10:09:46AM +0100, MJ Ray wrote:
> Dominic Hargreaves <dom <at> earth.li> wrote: [...]
> > Why not /usr/lib/cgi-bin, the designated place for CGI scripts?
> > (this is what I do for openguides).
> 
> In short, how do you reference that from Makefile.PL using $(INST...)
> and similar?

Ah, I can't answer that question, as the application I'm packaging uses
Module::Build and a custom build script (which is itself configurable).

> (Through $(INST...) and friends, MakeMaker also supports installations
> in /usr/local and /home, and reduces the assistance required from me
> for RPMs and Win32, so I'd really like to use it as a base.)
> 
> If it can't be done from Makefile.PL, I'm happy to move them there
> with a mv in debian/rules.

This sounds like the easiest option, yes.

Dominic.

--

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

Damyan Ivanov | 6 Jul 11:13

Re: Packaging a CGI with modules?

[CC added to MJ. Sorry if you're subscribed]

-=| Dominic Hargreaves, Fri, 6 Jul 2007 09:38:52 +0100 |=-
> On Fri, Jul 06, 2007 at 11:27:04AM +0300, Damyan Ivanov wrote:
> > -=| MJ Ray, Fri, 06 Jul 2007 08:54:52 +0100 |=-
> > > As well as having ITP'd koha, I am an upstream developer of it.
> > > Upstream, I am setting WriteMakefile()'s PM to move the files into
> > > good locations - for example, I'm currently putting the CGIs in
> > > $(INST_LIB)/koha/cgi-bin - and I intend to mv them with
> > > debian/rules to meet policy.  Is that the best
> > > MakeMaker-definable location for them to start in?
> > 
> > Sure. koha/cgi-bin for the CGIs, koha/lib for the modules (*.pm).
> 
> Why not /usr/lib/cgi-bin, the designated place for CGI scripts?
> (this is what I do for openguides).

I'd prefer to make the package more separate. I mean, if it puts the
CGIs in some "common" place, then one has to enable all the CGIs in
that "common" place, regardless of where they came from (koha or not).
With separate place, ScriptAlias will enable CGI support only to koha's
scripts and nothing else. For example, imagine user wants to use a
VirtualHost or a separate Location for koha.

BTW, MJ, what is the expected value for $(INST_LIB) in the pure
(non-Debian) installation and when used from debian/rules?

> > If there is some way to put custom path in CGIs' @INC, the IMO
> > correct place for the modules is /usr/share/koha/lib. If it is
> > troublesome to get that path in @INC, then install them

(Continue reading)

MJ Ray | 6 Jul 13:34

Re: Packaging a CGI with modules?

Damyan Ivanov <dam <at> modsoftsys.com> wrote: [...]
> This way one would be able to "make INST_LIB=debian/tmp", right?

I think you could, but make PREFIX=... or DESTDIR=... would probably
be more usual.

> If there is some way to put custom path in CGIs' @INC, the IMO correct
> place for the modules is /usr/share/koha/lib. If it is troublesome to
> get that path in @INC, then install them in /usr/share/perl5/

SetEnv in an apache VirtualHost config can be used, but the modules
are also used by some scripts the webmaster may want to use, so I'd
put them in the normal perl tree.

> > Also, I'm intending to use prompt() to obtain values to generate
> > configuration files.  Is there a slick way to get debconf to supply
> > prompt() answers,
>
> I am not sure. What is prompt? At what stage of the build/install
> process are these questions asked?

prompt is described in man ExtUtils::MakeMaker "Other Handy Functions".
I don't know what stage they're asked at.  I'm hoping during install.
If it's running non-interactively (debian build?) it uses defaults.

Damyan Ivanov <dam <at> modsoftsys.com> wrote:
> [CC added to MJ. Sorry if you're subscribed] [...]

I'm subscribed.  I usually remember to ask for CCs if required.

(Continue reading)

Jeremiah Foster | 6 Jul 14:48

Re: Packaging a CGI with modules?


On Jul 6, 2007, at 9:54 AM, MJ Ray wrote:
>
> What is the recommended way to package a CGI with its own modules?
>
This question is something I am interested in as well, would you be  
willing to share some information on your solution so that I can  
write a How-to document that I can use? Mostly for myself. :)

> This seems not very well-documented: not just for debian, but
> generally.  I'm using MakeMaker because it seems to be halfway
> portable.

You may want to look into Module::Install. I have had portability  
problems with it but it is new, provides an excellent interface and  
installs other pms that your package needs.

	Jeremiah

Damyan Ivanov | 6 Jul 15:09

Re: Packaging a CGI with modules?

-=| Jeremiah Foster, Fri, 6 Jul 2007 14:48:48 +0200 |=-
> 
> On Jul 6, 2007, at 9:54 AM, MJ Ray wrote:
> >
> > What is the recommended way to package a CGI with its own modules?
> >
> This question is something I am interested in as well, would you be  
> willing to share some information on your solution so that I can  
> write a How-to document that I can use? Mostly for myself. :)

No, no. Please publish it somewhere! It even can be placed on
pkg-perl.alioth.debian.org.

MJ, there is some general, high-level policy for web applications
that may be useful for you too. See [1]. Of course, I wouldn't be
surprised if you're already aware of that :)

[1] http://webapps-common.alioth.debian.org/draft/html/

--

-- 
dam            JabberID: dam <at> jabber.minus273.org

Jeremiah Foster | 6 Jul 15:18

Re: Packaging a CGI with modules?


On Jul 6, 2007, at 3:09 PM, Damyan Ivanov wrote:

> -=| Jeremiah Foster, Fri, 6 Jul 2007 14:48:48 +0200 |=-
>>
>> On Jul 6, 2007, at 9:54 AM, MJ Ray wrote:
>>>
>>> What is the recommended way to package a CGI with its own modules?
>>>
>> This question is something I am interested in as well, would you be
>> willing to share some information on your solution so that I can
>> write a How-to document that I can use? Mostly for myself. :)
>
> No, no. Please publish it somewhere! It even can be placed on
> pkg-perl.alioth.debian.org.
>
I am happy to publish it, but it must be looked-over by this list. I  
am not a DD nor as experienced in developing for debian as people  on  
this list. I do some technical writing however and have even been  
published so this project is something I will take seriously.

	Jeremiah

| 6 Jul 18:30

Re: Packaging a CGI with modules?

On 7/6/07, Damyan Ivanov <dam <at> modsoftsys.com> wrote:
> > On Jul 6, 2007, at 9:54 AM, MJ Ray wrote:

> > > What is the recommended way to package a CGI with its own modules?

> No, no. Please publish it somewhere! It even can be placed on
> pkg-perl.alioth.debian.org.

I have written a small blogpost some weeks ago. It was in response to
MJ Ray, but I don't know if he read it. Corrections are welcomed :)

http://howtorecognise.mine.nu/archives/111-About-installing-a-complex-perl-web-application.html

--

-- 
Martín Ferrari

Gunnar Wolf | 7 Jul 03:13

Re: Packaging a CGI with modules?

MJ Ray dijo [Fri, Jul 06, 2007 at 08:54:52AM +0100]:
> Perl sages,
> 
> What is the recommended way to package a CGI with its own modules?
> 
> This seems not very well-documented: not just for debian, but
> generally.  I'm using MakeMaker because it seems to be halfway
> portable.

Umh... Are the modules only useful for your CGI application? Don't you
think they _might_ be useful for something else?

I think I would prefer having several quite-usual packages than just a
strange one. If you split your stuff in, say, libkoha-perl (which is
just a standard lib.*-perl package, like all the hundreds you have
seen here and there) and the CGI app itself in koha (which would fit
IMHO better in /usr/share/koha - Rationale a bit later on), any person
trying to figure out what you did or why you did it that way would be
far happier.

Now, why /usr/share/koha? Because that way, you can also drop a config
snippet under /etc/apache2/conf.d/koha (and/or possibly similar
locations, if you like other webservers - or just documenting what's
needed for that). I feel having CGIs under /usr/lib/cgi-bin is almost
as dirty and 1995-ish as publishing them under
http://www.my-site.org/cgi-bin/koha.pl - Just make them take
http://www.my-site.org/koha or http://koha.my-site.com!

> As well as having ITP'd koha, I am an upstream developer of it.
> Upstream, I am setting WriteMakefile()'s PM to move the files into

(Continue reading)

Julian Mehnle | 7 Jul 10:46

Re: Packaging a CGI with modules? -- Try Module::Build!

Gunnar Wolf wrote:
> In the end, I have to wholeheartedly agree with Martín Ferrari: Perl's
> MakeMaker and similar tools (Module::Build, Module::Install, etc.) are
> great for modules, but suck for complex setups. But that's where you
> use debian/rules 

MJ, Gunnar, Martin, what MJ is trying to do may be awkward to achieve with 
MakeMaker, but it's a breeze with Module::Build (don't know about Module:: 
Install, but I guess it can do it easily, too).

For example, look at this package of mine, which can be installed
"manually" via Module::Build but also has debian/ infrastructure built on 
top of that:

  http://www.bitshapers.com/thingy
  http://dev.bitshapers.com/source/thingy/trunk/
  http://dev.bitshapers.com/source/thingy/trunk/Build.PL?view=auto

(I could have suggested other packages that actually are in the Debian 
archive, such as courier-filter-perl, but that's not a CGI app, and thingy 
is the one with the most comprehensive Build.PL I can offer.)

Julian.

Dominic Hargreaves | 8 Jul 11:25

Re: Packaging a CGI with modules?

On Fri, Jul 06, 2007 at 08:13:39PM -0500, Gunnar Wolf wrote:

> Now, why /usr/share/koha? Because that way, you can also drop a config
> snippet under /etc/apache2/conf.d/koha (and/or possibly similar
> locations, if you like other webservers - or just documenting what's
> needed for that). I feel having CGIs under /usr/lib/cgi-bin is almost
> as dirty and 1995-ish as publishing them under
> http://www.my-site.org/cgi-bin/koha.pl - Just make them take
> http://www.my-site.org/koha or http://koha.my-site.com!

Policy 11.5 - tells us where CGI scripts/programs should live.

This does not mean that you have to use the application as
http://www.my-site.org/cgi-bin/koha.pl...

Dominic.

--

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

Don Armstrong | 8 Jul 11:33

Re: Packaging a CGI with modules?

On Sun, 08 Jul 2007, Dominic Hargreaves wrote:
> On Fri, Jul 06, 2007 at 08:13:39PM -0500, Gunnar Wolf wrote:
> 
> > Now, why /usr/share/koha? Because that way, you can also drop a config
> > snippet under /etc/apache2/conf.d/koha (and/or possibly similar
> > locations, if you like other webservers - or just documenting what's
> > needed for that). I feel having CGIs under /usr/lib/cgi-bin is almost
> > as dirty and 1995-ish as publishing them under
> > http://www.my-site.org/cgi-bin/koha.pl - Just make them take
> > http://www.my-site.org/koha or http://koha.my-site.com!
> 
> Policy 11.5 - tells us where CGI scripts/programs should live.
> 
> This does not mean that you have to use the application as
> http://www.my-site.org/cgi-bin/koha.pl...

Right, but it does make it rather difficult to have a specific set of
CGI scripts served by one vhost and not by another.

This is why it's a should directive, not must, and frankly, may well
need to be revisted in the future.

Don Armstrong

--

-- 
Leukocyte... I am your father.
 -- R. Stevens http://www.dieselsweeties.com/archive.php?s=1546

http://www.donarmstrong.com              http://rzlab.ucr.edu

(Continue reading)

Gunnar Wolf | 9 Jul 14:55

Re: Packaging a CGI with modules?

Don Armstrong dijo [Sun, Jul 08, 2007 at 02:33:27AM -0700]:
> > > Now, why /usr/share/koha? Because that way, you can also drop a config
> > > snippet under /etc/apache2/conf.d/koha (and/or possibly similar
> > > locations, if you like other webservers - or just documenting what's
> > > needed for that). I feel having CGIs under /usr/lib/cgi-bin is almost
> > > as dirty and 1995-ish as publishing them under
> > > http://www.my-site.org/cgi-bin/koha.pl - Just make them take
> > > http://www.my-site.org/koha or http://koha.my-site.com!
> > 
> > Policy 11.5 - tells us where CGI scripts/programs should live.
> > 
> > This does not mean that you have to use the application as
> > http://www.my-site.org/cgi-bin/koha.pl...
> 
> Right, but it does make it rather difficult to have a specific set of
> CGI scripts served by one vhost and not by another.
> 
> This is why it's a should directive, not must, and frankly, may well
> need to be revisted in the future.

Yes... Now that you point it out, this looks like a bit of policy that
can (and should) be updated. It does not mean the URL should be like
that, but... It makes no sense to have it that way.

Specially if you start talking about webapps that are _not_ cgi-bins
anymore - Think of anything that works from an application server
perspective (i.e. Zope, Rails, Embperl and other mod_perl-based apps,
and a long etc.) - They are libraries that can have quite intrincated
directory structures. Having them in /usr/lib/cgi-bin looked like a
nice idea a long time ago, maybe... But I don't think that's the case

(Continue reading)

Return

Return to gmane.linux.debian.devel.perl.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane