Installing Bibledit packages on Debian (was: Re: [be] Installing/Updating Bibledit from http://ppa.launchpad.net/pkgcrosswire/ppa/ubuntu? )

[Jonathan Marsden]

Teus Benschop wrote:

>> (1) This apparently refers to bibledit 3.8 -- which does not exist yet,
>> as far as I know?  A typo, or a prophecy? :)

> It's just for convenience, so people know how to install the version in
> git, that, hopefully, eventually will be version 3.8. The thing is that
> libwebkit came in, a dependency not yet required by version 3.7. A place
> was needed to put that information down somewhere.

OK.  A similar page for 3.7 (minus the libwebkit info) might be good as
well, unless 3.8 is coming very soon.  Seeing pages for 3.6 and 3.8, but
not for 3.7, seemed odd somehow.

> For the site, thinking of the users we have, the GUI based instructions
> are preferred. Those who prefer the command line may extract the command
> line version out of that.

Well, it's often non-trivial to mentally convert a lengthy description
of how to use a GUI into a one line command... see below for a current
and highly relevant example.

BTW, if the primary audience is novices, why do the instructions
currently ask people to use System -> Administration -> Synaptic Package
Manager instead of the more basic System -> Administration -> Add/Remove
Packages (which runs gnome-app-install) ?

> Yes, I prefer a one similar to the ubuntu one for debian. Html right now
> is preferred, because we don't use DocBook XML yet for creating the
> documentation. Thanks for your offer to create that information.

OK.  Tell me whether the page at
http://computeroptions.net/sword/bibledit_debian.html meets your needs.
 It ended up longer than the Ubuntu one, mostly because it does not
refer people to an external page for instructions on adding a repository.

Now we have a GUI/command line example.  How can a user extract from the
GUI-oriented description of how to add a repo on that help page I just
wrote, that the quick way to do it is something like:

  su -c "echo 'deb http://ftp.debian.org/debian/ testing main' \
    >/etc/apt/sources.list.d/testing.list && \
    apt-get update && apt-get install bibledit"

I don't think many people, even those who have fairly decent command
line skills, would be able to extract this command from the GUI info.
Yet it is *much* shorter and simpler to cut and paste this one command
line from a web page window into a shell window, than to do all the GUI
steps ... you just select the command text, ctrl-c, middle-click on the
shell window, and press Enter.

If we need to avoid typing even just the password into the shell window,
because people *really* don't like using the shell, we could even use:

  gksu "bash -c 'echo \'deb http://ftp.debian.org/debian/ testing main\'
    >/etc/apt/sources.list.d/testing.list &&
    apt-get update && apt-get install bibledit ' "

so the users get a pretty GUI password dialog, not a shell one :)

One last variation: no terminal window need even be opened... The user
hits Alt-F2, types gksu into the dialog box that opens and clicks OK.
Then the user selects the command, ctrl-c, and then middle clicks to
paste it into the Run: field and clicks the OK button.  That's fast,
truly minimal typing, and the user never even *sees* a command shell
this way.

Nevertheless, my proposed help page follows your advice to specify only
the GUI approach, and does not include any shell commands to use :)

> Yes, it would be faster, but some users are new to Linux, or even those
> not very new to it, and they prefer the information to be given to them
> step by step and use the GUI. It is only that compiling from source must
> have the command line, so the new users cannot escape from that.

I somewhat disagree with this last sentence.

Idea #1: You could put a small script on the web site and have users
click on a link to it; appropriately set up, I think this could be made
to untar and compile the app with no user typing at a command line.

Idea #2: Worst case, they'd have to download and save the script file,
and then use their GUI file manager (Nautilus or whatever they use) to
make it executable and then double click on it to execute it.  No
command line use at all would be needed, and stuff still gets compiled!
 I just tested this approach here... it works fine.

Idea #3: Using the Alt-F2 gksu idea from earlier to copy and paste the
command text to do the untar and compile and install -- users could
compile and install the tarball sources without even seeing a shell
window ... although if it fails, troubleshooting without such a window
could be awkward :)

But the whole idea of novices who are uncomfortable at the command-line
compiling anything from a source tarball seems rather strange; it should
not, generally speaking, be necessary for end users to do this.

> It would be a great help if packages were described for them how to
> use that. This would keep them all in the GUI, so they would never
> have the command line in front of them.

See above for (a) using packages and (b) compiling the source tarball,
both without a command line (shell window) in front of them :)

Using existing packages is better for end users, of course, for all of
the Linux distributions that have packages available.  That's why I'm
doing this packaging work!  But realistically, you probably won't get
up-to-date Bibledit packages for many less popular Linux distributions,
without doing a lot of packaging yourself.

Incidentally, speaking of easily installing packages: we can now embed
apt-urls into web pages.  So, once we have the packages in the official
repositories for current Debian and Ubuntu versions, the install
instructions become very close to just "click on this link; when asked
what to do with it, select "Use Gdebi Package Installer" (which is the
default) and click OK".  apt:bibledit?refresh=yes is an example of such
a URL.

Until then, we need to have info on adding a PPA or the Debian testing
repository first.

I suspect using apt-url's could be a better (cleaner, shorter) approach
than describing use of Synaptic or gnome-app-install; if I get inspired
I'll test my theory!  I hope webkit handles apt-urls in basically the
same way Firefox does...

> Agreed, some are very old, and could be removed. But updated ones would
> need to replace those, and that needs a bit of time. If you like pls.
> submit a task for updating all help for all distros.

I see you already added that task :)

> I wasn't aware of these strict rules that the Debian folks put out for
> us to swallow (and even if I was aware of that, I wouldn't care...). 

Well, as an end user I can definitely understand that viewpoint!  But as
a developer, you perhaps ought to care at least a little.  If you create
an application to *need* a library that Debian (or some other popular
distribution) feels should not be linked to GPLed code, you
(accidentally) prevent yourself from getting your app packaged for and
included in that distribution.  So, even if you disagree with their
interpretation of the legal issues, it can be practically useful to know
what to do and what to avoid, as a developer, so you stay far away from
any such perceived licensing issues.

Jonathan