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

[Jonas Smedegaard]

On 11-04-28 at 08:00pm, Edvin Dunaway wrote:
> yes, I agree.
> we need to settle on what will be in that tarball and as well create a 
> reposatory for git-buildpackage; BRE: I'll contact you tomorrow about 
> it. I've been looking into it and so far it's been quite straight 
> forward, though I'm still getting used to git.
> the documentation that I've been reading is here:
> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
> 
> Jonas: any hints, ideas or specifications on your behalf?

Above looks like the official documentation for git-buildpackage.  
That's a good read, but beware that it covers several ways to use the 
tool, not necessarily the most common or the one currently best 
integrated with other packaging tools.  Have a look here as well - that 
seems (from a quick glance) to better cover that other end of the scale: 
http://wiki.debian.org/PackagingWithGit

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.

Commonly sysadmins are conservative - hate it when scripts try to be 
clever.  Distributors are even more conservative - if needing to later 
change a comma in the script e.g. due to a security bug, thousands or 
millions of users may be affected and not expect an already installed 
tool to change behaviour *at* *all* during a stable security update.  
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.

So I stringly urge you to revisit how you design your tool.  To store 
boring old-style config files separately, to include a README containing 
runtime usage info, an INSTALL document containing setup info, and a man 
page containing more or less the same as the README but in a very strict 
composition. And so on and so on.  Basically: Look at how others ship 
code, and mimick most possible of that, instead of trying to be smarter!


Edvin: I recommend to avoid the "digest" mode of subscription to the 
mailinglist, as that disrupts the naming of threads. :-)



Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-pagekite-devel/attachments/20110428/b720416b/attachment.pgp>