Not meaning to flood the list, but one more thought on this...
I think it may be wise to state that our goals/agendas probably are
(and should be) different:
You rightly want to provide emilda source that is easy to install and
configure anywhere, on any *nix (or even windows?) system, and in any
directory.
The Debian package speaks to only a sub-set of your population, and
needs to conform to normal Debian policies and practices so that it
behaves in ways (and places files in locations) that are familiar to
Debian users. Thus it is a _specialization_ of the more generic emilda
source package.
You should feel no pressure to conform to Debian unless you think
it would be a good thing for all your users or otherwise increases
your overall user base.
On Thu, Aug 19, 2004 at 08:13:45AM -0600, wrote:
> Hi Christoffer,
>
> Thanks for responding...some comments below:
>
> On Thu, Aug 19, 2004 at 04:12:00PM +0300, Christoffer Landtman wrote:
> > David Everly wrote:
> > >Note that the emilda packages put CGIs in the standard Debian location,
> > >so much of this should be handled automatically:
> > >
> > >/usr/lib/cgi-bin/emilda/MARC.pl
> > >/usr/lib/cgi-bin/emilda/PDF.pl
> > >/usr/lib/cgi-bin/emilda/barcode.pl
> > >/usr/lib/cgi-bin/emilda/book_manager.pl
> > >
> > >(dpkg -L emilda will show the location of most of the emilda files and
> > >directories, /var/lib/dpkg/info/emilda.* will show the rest of the
> > >pre/post install logic)
> > >
> > >I also assume you are using the latest package (0.20040818.cvs-1).
> > >
> > >
> >
> > Yes, I have the latest package. I just noticed what You pointed out that
> > the perl folder no longer is under the source folder of Emilda. Is there
> > any particular reason why doing it this way, or just "bad habit" ? ;-) I
> > personally would prefer to have the perl folder under emilda so that it
> > would be easier to manage/administer the system, and just adding a few
> > more directives in the emilda.conf. But if You can convince me why to
> > have it in cgi-bin, I'm willing to change oppinion. The reason why I
> > would like to define it with directives, is that this would allow me to
> > use mod_perl to execute the scripts, not only the cgi-module.
>
> You should be able to use the layout you are comfortable with, since it
> is your package. However, Debian requires that its packages follow the
> Unix Filesystem Hierarchy Standard and other Debian standards.
>
> In general, you can find these under "Packaging" at:
>
> http://www.debian.org/devel/
>
> I won't go into all the reasons since they are many and included in the
> above link. However, I do believe Debian Policy is a Good Thing,
> providing standardization, predictability, and automation that I have found
> lacking in certain other distributions.
>
> However, here is the specific policy that drove me to move the perl cgi
> to its present location:
>
> http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl
>
> "Cgi-bin executable files are installed in the directory
>
> /usr/lib/cgi-bin/cgi-bin-name
>
> and should be referred to as
>
> http://localhost/cgi-bin/cgi-bin-name";
>
>
> > The actual problem arose when i created an emilda-cvs folder that was
> > just a new source-folder using the same database and the same configs as
> > You supplied Emilda package. There when having the perl folder under the
> > source folder, I had to add directives to allow perl execution in this
> > folder.
>
> This is as I suspected. A normal user would simply install the package
> and be fine. A developer would know if the httpd.conf file has been
> altered and what do do to fix it.
>
> > I also noticed that You have moved the Z39.50 servers into a separate
> > config, /etc/emilda/z3950-servers.inc or similar. I'm not sure if there
> > is actually a need for this as I have scheduled to move this entirely
> > into MySQL by the next milestone release (1.3 probably), but this is
> > also debateable.
>
> You can do this how you like, but the Debian/FHS standards indicate
> that configuration files belong under /etc. One of the benefits of
> doing this is that the upgrade of the Emilda package from one revision
> to the next will not blindly overlay the z3950 settings others have
> customized for their libraries.
>
> It is trivial to do this for the Debian package and it can easily be
> eliminated or modified when it becomes managed by the database or
> otherwise altered in your generic package.
>
>
>
> Ultimately I want to follow all the Debian standards in hopes that I
> may find a sponsor so that Emilda can be included in Official Debian.
> However, this need not require modifications to the way you develop or
> organize Emilda, since they are contained in discreet patches that are
> automatically applied to Emilda during Debian package build/generation.
>
> Thanks for responding and please let me hear any additional comments and
> questions.
>
> Dave.
>
> --
> Encrypted Mail Preferred:
> Key ID: 8527B9AF
> Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF
> Information: http://www.gnupg.org/
>
>
> ASCII ribbon campaign:
> () against HTML email
> /\ against Microsoft attachments
> Information: http://www.expita.com/nomime.html
--
Encrypted Mail Preferred:
Key ID: 8527B9AF
Key Fingerprint: E1B6 40B6 B73F 695E 0D3B 644E 6427 DD74 8527 B9AF
Information: http://www.gnupg.org/
ASCII ribbon campaign:
() against HTML email
/\ against Microsoft attachments
Information: http://www.expita.com/nomime.html
signature.asc
Description: Digital signature
|
