Re: first install of RefDB .debs

Thanks David for all the tips. Ubuntu has started a backports service
for Dapper (the later version) which seems to be taking care of some of
the problems.

So the forking may have been only temporary having to do with the
release of the new version.

I'll go through all your suggestions carefully and when I have something
that is safer and more friendly propose storing it somewhere.

-d

On Sat, 2006-08-07 at 12:42 +0930, David Nebauer wrote:
> Hi Dan,
> 
> > I am understanding why commercial programs like Oxygen or Crossover
> > Office tend to skip the whole distro specific thing (or offer rpms only)
> > in favour of, as far as I can tell, building from source using a script.
> >
> > It seems to me it might be
> > better to take a page out of the commercial developers book and offer a
> > set up script that takes care of things on the basis of a couple of
> > responses.
> >   
> 
> You are right that maintaining debs for apps on the cutting edge can be 
> difficult.  Having said that, installing from a good quality deb is 
> still the easiest and quickest way for a newbie to go from zero to fully 
> functioning install.  Now the kinks have been ironed out from the refdb 
> packages they should be usable for Debian newbies.
> 
> That brings us to the problem of incompatibility with other 
> distributions in the Debian universe, such as Ubuntu.  I see where your 
> script fills a need there.
> 
> With regard to the script itself I'd like to make some observations and 
> suggestions for improvement.
> 
> 1. Using debs or CPAN source for perl modules
> 
> Many perl modules are available as debs.  It is almost a philosophical 
> choice as to whether you prefer to use debs when available or stick to 
> CPAN.  I note your script installs Text::Iconv from CPAN source rather 
> than the libtext-iconv-perl deb.  There is an obvious danger here of 
> overwriting deb-installed files -- which wouldn't be playing nice.
> 
> I suggest either switching to installation via deb or at least checking 
> the status of libtext-iconv-perl and installing from CPAN only if the 
> deb is not installed.
> 
> I haven't checked fully but this may apply to other standard perl 
> modules in your script.
> 
> 
> 2. libdbi* and libdbd*
> 
> These libraries are available as debs in the libdbi.sourceforge.net 
> repository.  Would it not be easy to install from them?  The script 
> would have to check '/etc/apt/sources.list' to make sure the libdbi 
> repository was sourced.
> 
> 
> 3. Checking /etc/apt/sources.list
> 
> Since this is pitched at newbies would it not be better to parse 
> '/etc/apt/sources.list' on their behalf to check that required 
> repositories are available?  You need notify them only if the file is 
> not suitably configured.  At that point execution could abort with 
> advice on where to get further information.
> 
> 
> 4. Sudo RSI
> 
> There are 26 'sudo' statements in the script.  Would it not be better to 
> run the script as root and save our poor newbies all that hassle?
> 
> 
> 5. Maintainability of version numbers (1): Use of variables
> 
> The first thought that hit me on looking at the script was that all the 
> specific version numbers make it a maintainability nightmare.  I'd be 
> inclined to handle version numbers by variables and have them all 
> grouped together at the top of the script for easy editing.
> 
> 
> 6. Maintainability of version numbers (2): Use CPAN(PLUS) module
> 
> If you use CPAN or CPANPLUS to install modules you will make maintaining 
> the script much easier.  For example, the following commands:
>     wget 
> http://search.cpan.org/CPAN/authors/id/P/PE/PETDANCE/MARC-Record-1.38.tar.gz 
> &&
>     cd MARC-Record-1.38 &&
>     perl Makefile.PL &&
>     make &&
>     sudo make install &&
>     cd ..
> are replaced, in the case of CPANPLUS, with
>     cpanp -i MARC::Record
> 
> This will install it from scratch if it is not installed or, if already 
> installed, update it if a later version is available.  It also 
> automatically installs any module dependencies.
> 
> It also has the *major* benefit of freeing you from maintaining version 
> numbers and specific CPAN directory filepaths for those modules.
> 
> 
> 7. Choice of database
> 
> You are forcing use of MySQL as the database backend.  There's nothing 
> wrong with that in itself, but you might want to consider letting the 
> user choose between mysql, postgresql, sqlite or sqlite3.
> 
> If you do intend to force use of only one, can I suggest sqlite?  It has 
> a much smaller footprint than mysql.  In addition, it doesn't require a 
> password -- put another way, it accepts any password from refdb.  This 
> makes set up much easier as user input is not required.
> 
> 
> 8. Feedback on failure
> 
> You have chained together dozens of commands using '&&'.  A newbie, from 
> his/her point of view, will see screens of text flying by, periodically 
> interrupted by a request for the root password.  If one of those 
> commands should fail they will be left trying to make sense of a 
> mystical failure message, possibly relating to a perl module they have 
> never heard of, and no idea how to fix the problem.
> 
> While it takes more work, perhaps each installed element, perl module or 
> source tarzip, should be wrapped in it's own block with a specific error 
> message in the event of failure.
> 
> You could fairly easily use a couple of functions to do the repetitious 
> work and prevent code duplication.
> 
> 
> 9. Cannibalise refdb-svn
> 
> I created a script, 'refdb-svn', which fills a slightly different need 
> to yours.  It is designed for users who want to install from, and keep 
> up to date with, the latest refdb svn source.  It has some convenient 
> functions you may want to steal.  A link to the script can be found at 
> the bottom of page <http://refdb.sourceforge.net/download.html>.
> 
> 
> On the whole, I think your install script could be very useful for 
> newbies.  RefDB is a sprawling application that utilises dozens of other 
> tools.  When first encountered it can be very daunting.
> 
> Regards,
> David.
-- 
Daniel Paul O'Donnell, PhD
Associate Professor and Chair
Director, Digital Medievalist Project
<http://www.digitalmedievalist.org/>
Department of English
University of Lethbridge
Lethbridge AB T1K 3M4

Tel. +1 (403) 329-2378
Fax. +1 (403) 382-7191

:@wiglaf (dapper ubuntu)


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642