[wpkg-users] how about managing wpkg packages files with a vcs

[Rainer Meier]

Hi,

informatique src wrote:
> * come up with some common rules for standardizing wpkg packages files
> writing  (naming scheme, versioning, path to executable...)

WPKG can be used in various different ways in various environments and is very
flexible. Imposing naming rules is quite difficult and would always limit the
ways WPKG is used (limits flexibility).
Some "best practice" rules like the use of a %SOFTWARE% variable in WPKG client
already exist. This makes most of the packages "portable" and re-usable.

However there are always multiple ways to deploy a software. Some like to use
shell-scripts to perform multiple actions during installations, some prefer to
define multiple commands within the package definition. Both is correct and
fully supported.

Another example is that some users use AutoIt to script installers while people
like me avoid this "click-scripting" like the plague and use shell-scripting,
re-packaging and/or SFX extractors instead. But I accept package contributions
using AutoIt because having a way of silent installing is better than having
nothing. So giving a clear rule is very difficult.

Versions of the packages is a story for its own. Previous WPKG releases (prior
to 1.0) only supported an integer value for the package revision and users were
used to increase this counter each time they did a change. Today WPKG 1.1.x
supports much more complicated version numbers and it got more common to use the
software-revision within the revision field too.


> * then use a vcs (subversion or any dvcs) to check in/out those files.
> We could have a single branch or use the stable, testing, development
> branch scheme used by others

SVN is a VCS (Version Control System) but it's not distributed (DVCS). Using a
DVCS system is more complex to developers than a client-server VCS like CVS or SVN.
In general I have doubts that storing package templates within a VCS would
increase usability and contribution. Currently examples and package templates
are stored on our Wiki page which is in fact a VCS too (keeps page history).
The main advantage I see when using a Wiki is that it's much easier to
contribute. Even people without development background can use a Wiki. I would
expect much less people to contribute to the package templates if they would
have to install an SVN client, learn about SVN in general, log in to the system
(typically SVN write-users have their personal account) and then add the sources
correctly to the repository.

In addition the Wiki encourages people to write a few sentence of explanation.
In a VCS I think that most contributors would just check in an uncommented XML
file without any comments or README and at the end it's much less helpful to new
users.

Another problem would be that contributors might start uploading binaries
(installers) to the repository too which is a problem because of copyright and
licensing issues (apart the fact that I really don't like binaries within a
source repository).


> Writing the packages files is what takes time, so it would be nice if we
> could find a way to put in common our efforts :-)

Well, I agree that some packages within the Wiki are not of the best quality but
it allows everybody to contribute or to unify them.

The biggest concern I see when using a VCS is as I stated: Accessibility and
Usability. In order to convince as many people as possible to contribute we need
to keep the hurdle as low as possible. And using the browser to edit a Wiki page
is for sure a lower hurdle than installing an SVN client and following a
document to prepare a package to be checked in properly.


Just my $0.05, I ask others to give their opinion as well.


br,
Rainer