[Pkg-pagekite-devel] Pkg-pagekite-devel Digest, Vol 2, Issue 2

[Bjarni Rúnar Einarsson]

2011/4/28 Jonas Smedegaard <dr at jones.dk>

> Regarding upstream tarball releases: The description on your code being
> all contained in a single script unfolding itself automagically and
> therefore not needing common things like config file or documentation,
> really really worries me!  That might be cool when you serve the code
> directly to your end-users, but un-cool when distributed by e.g. Debian.
>

Of course, that's part of the packaging project - define what the system
integration should look like and make sure PageKite does that and only that
when used as a background daemon.

I've spent much of the last 15 years working as a sys-admin, so I know
exactly what you are talking about. :-)  I was just explaining why I don't
have all those things already, the tool has primarily been distributed as a
user-space utility, not a system component.  I also realize that as soon as
PageKite is packaged, the "API" of its command-line arguments, log-file
format and overall behavior will have to remain backwards compatible as much
as possible.

However, that said, at the moment the most popular use-case for PageKite is
as a helper tool for web developers - not as a system-level background tool
at all.

They use it interactively at the console, switching it on or off and
potentially reconfiguring it many times a day. The same code-base is also
used on Windows and Mac OS X, where expectations are quite different from
those of a Debian sysadmin. That is where the "cleverness" comes in, trying
to provide a good user interface for these users.

Obviously I would like it if debian packages could serve serve these users
as well - not just sysadmins.

Perhaps we will want more than one package?  One which provides just the
tool for interactive use, and others which depend upon it and do different
types of stable system integration.  Eventually there will be a GTK-based
GUI package as well. Expected 'roles' for pagekite are as follows:

  1) system-level tool for exposing a HTTP or SSH server to the Internet
(back-end)
  2) system-level tool for helping others expose their servers (front-end)
  3) interactive tool for developers (interactive backend, cli)
  4) interactive tool for end-users (interactive backend, GUI)

Of these, 1-3 all exist and could be packaged, 4 is in development.  1 and 2
are potentially relevant to the FreedomBox project, those are probably the
use-cases you had in mind when you became worried. :-)

I am not sure all of these roles really fit in a single package, as the
requirements and behavior of each are quite different.  One possibility is
to package for 3), with configs for 1) included but disabled by default, and
configs for 2) in /usr/share/docs/, and make 4) depend on that.

Another is to make them all separate packages, where 1) and 2) and 4) depend
on 3).


Tools should be reliable, not clever.  Not create config files
> automagically, but contain sensible internal defaults and/or fail if
> crucial config info is missing.
>

At the system level yes, no argument at all.

As a user-space tool, the features will be there but the tool still won't
even touch the file-system and change anything without being asked to by the
user.  But being able to save the configuration you've carefully constructed
using a GUI or wizard or something is rather important, wouldn't you say?
:-)

-- 
Bjarni R. Einarsson
The Beanstalks Project ehf.

Making personal web-pages fly: http://pagekite.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-pagekite-devel/attachments/20110428/eb68c576/attachment-0001.htm>