[be] [task #10011] runtime vs buildtime dependencies

[Teus Benschop]

Follow-up Comment #1, task #10011 (project bibledit):

I think this should be not the matter of bibledit but of the packager 
and should be resolved by setting dependencies accordingly. At the most 
I would expect bibledit to put up a notice "without A,B,C installed and 
running following capabilities are not there". You could do this by 
sending a message to self and see if it arrives. If not bibledit knows 
it needs to put up a message.

Within Ubuntu many packages will not offer full functionality without 
others present - Lyx's version control e.g. relies on svn installed.

Some of these runtime dependencies are crucial some less so. Depending 
on the level of necessity Ubuntu/Debian offer a graduated system of 
dependency - IIRC straight dependency. recommendation and suggestion.

Straight dependency would be sqlite and gtk libraries, recommendation 
SSH, suggestion Apache, Lighttpd or other PHP coapable server. Or a 
variation on this.

I am sure Suse and Redhat have a similar graduated set of levels, though 
I do not know.





Right, but such use is only at run time, not at build time, so logically 
the check should happen at run time not build time, shouldn't it? 
Perhaps the check should happen only the first time in a Bibledit 
session that a user tries do perform an operation that will need it.

I suppose I see this from a packager's viewpoint... to me, there are 
build requirements, and there are runtime requirements, and these may 
overlap, but they are often not exactly the same.  Documenting both 
kinds of dependency (and being clear about which is which!) helps both 
those compiling from a source tarball and those packaging the software.

> Bibledit's policy is to check at build time for any the binaries that
> ever could be needed. Any dependencies would be documented in the source
> of the build time checker, which is a file configure.ac in the root of
> the package. If these are covered, then it would be fine.

This works very well for build-time dependencies, I think this approach 
makes good sense for these.  It is logical, and well understood by 
people compiling software.  It is easy for someone compiling the code to 
see quickly what is missing, because configure tells them (just like it 
told me about SSH being needed, once I compiled BE in a minimal build 
environment instead of on my workstation!).  It might be nice to have a 
list of these in the README file, so that the person concerned can plan 
ahead a little and download them all before starting to try and compile 
Bibledit, but that's a "luxury", not an essential, and the HTML docs for 
each OS cover that kind of ground anyway.

However, I suspect that this (build-time only checking) approach works 
less well for anyone doing binary distribution, whether creating and 
distributing packaged binaries or just copying files around "by hand" so 
only one person has to actually compile the application.  In this case, 
run time checks are more useful, because they will "catch" more issues, 
and also because they can be more descriptive to the end user.  Indeed, 
they can even lead to modifying Bibledit behaviour dynamically to suit 
its (incomplete) environment, such as greying out BE menu items that 
will not work because some tool they need is missing, or (even better, 
perhaps?) popping up a message indicating exactly what tool is needed 
before this particular menu item will work.





Once this dependency becomes "real", I would encourage you to document 
it somewhere in the source tarball (README file? INSTALL file?) so that 
someone who receives *only* the source tarball has all the information 
they need to build, configure and use Bibledit readily available to 
them.  Such a user will read the README and INSTALL files, but will 
probably not read all the HTML files, before building the application.



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?10011>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/