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

[Chris Wilcox]

> 
> 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.

 

I don't really find creating the package xml files a big problem, there are huge resources online for silent install commands nowadays, wpkg.org, appdeploy.com etc etc.  The huge time saved from using WPKG easily makes up for the not that long of a time to create a new package xml for me.

 

I guess I should update the WPKG wiki more than I do though, as I've plenty of programs in use that are not in it.

_________________________________________________________________
Get the best of MSN on your mobile
http://clk.atdmt.com/UKM/go/147991039/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20090620/c579f55b/attachment-0002.html>