[Gpg4win-devel] claws extensions

[Marcus Brinkmann]

At Tue, 14 Oct 2008 09:36:02 +0200,
Bernhard Reiter wrote:
> On Mittwoch, 1. Oktober 2008, Marcus Brinkmann wrote:
> > the claws extensions bring up an interesting issue.  They seem to be
> > the first packages which have different build dependencies from
> > installation dependencies, at least if we install them implicitely
> > when claws is installed.
> 
> given that claws grows in complexity, at one point in the future we should 
> consider a seperate claws installer that needs Gpg4win-X to do crypto.

First, let me note that after review, this wasn't the first packages
with that property.  We have one other example where the ordering was
different, so it wasn't new after all, just less well understood.

In addition to what Werner said, what you propose only makes sense if
a proper packaging system is used that can automatically resolve such
dependencies, and then all of gpg4win should be split into individual
packages, much like Debian, but with a simpler GUI.

Picking out claws is not a good idea: There are many technical reasons
against splitting it out, given the current installer technology, and
the same reasons keep Kleopatra in as well, despite its size and the
fact that it is the only component in gpg4win that actually comes with
an alternative (GPA).  There is no other free e-mail program in
gpg4win right now.

Also, claws is the only third party project that voluntarily works on
improving gpg4win, without having a $$$ contract.  We are free-riding
on claws' contributions, and kicking them out would send completely
the wrong message.  You know how this would look, even if you don't
mean it that way.  Instead, we should make a donation, IMO.  Colin has
helped to make gpg4win 2.0 a much better and more finished product.

If there is a group that dislikes having diversity, we can make
customized installers with very little effort as part of a support
contract, or they can roll their own build, like we have done with the
light installer.  Unfortunately, such builds can not peacefully
coexist, as their core elements can not be shared automatically nor
duplicated.  But this is exactly the packaging problem.  If we had a
solution for that, we would not be in the business of making a big
monolithic package in the first place.  So the snake bites its own
tail.

I have sympathy for the problems that the gpg4win packaging creates
for the KDE project.  It is not a pleasant situation to be in.  But
the problem is the same for *any* application on Windows that wants to
use gpg.  We don't have a solution.

gpg4win today is: (1) an autobuilder, (2) a package manager, (3) a
distribution.  But the package manager and distribution are not
extensible by third parties at all.  Good enough for an application,
but bad for a platform (gpg).

A major project could be a redesign of gpg4win to make it more modular
and easier extensible.  But, to do it right, this would IMO mean to
port dpkg and apt-get to windows.  There already are similar projects
out there, but I did not inspect them.  MSI, by the way, could replace
the dpkg part of the equation, but not the apt-get part.  It would be
critical to find broad support among free software ports to windows
for such a solution, so that it would be a one-stop platform.

Actually, to me this sounds like something that GNOME and KDE should
sort out among themselves, maybe as part of freedesktop, and then
gpg4win could just ride the wave.  I don't know if there are already
such efforts.  The GNOME and KDE platforms are much bigger, and there
should be larger pressure for them to come up with a solution.  How do
all the programs get to share glib and dbus?  When we know the answer
to that one, we may be smarter.

Thanks,
Marcus