Jonas: ok, I'll take a look at that Wiki, thanks.<br>regarding the all-in-one file, we have broken the configuration down to a few rc files (pagekite.rc, which can include local.rc, and also .pagekite.rc in ~/ ) but I guess we could use a conf file if needed.<br>
although the pagekite.py is doing all the work, you can customize alot in the .rc/.conf.<br><br><br>I was thinking of the following structure for default locations of files and binaries, for starters:<br><br>/etc/init.d/pagekited<br>
/etc/logrotate.d/pagekite<br>/etc/pagekite/<br><div style="margin-left: 40px;">-pagekite.conf (if needed?)<br></div><div style="margin-left: 40px;">-pagekite.rc<br></div><div style="margin-left: 40px;">-local.rc<br></div>
/home/user/pagekite/wwwroot/ (optional for the built in pyhttp daemon?)<br>/home/user/pagekite/.pagekite.rc<br>/usr/bin/pagekited<br>/var/log/pagekite/kitename.log<br>/var/run/pagekited.pid<br><br>most of this can be done via .rc/.conf and daemon parameters<br>
BRE: what's your input on this?<br clear="all"><br><br>Jonas: yes, I forgot to switch when I subscribed, but after getting the batch yesterday I promptly changed the settings :p<br><br>Edvin Dunaway<br><a href="mailto:edvin@eddinn.net">edvin@eddinn.net</a><br>
+354 8229344<br>
<br><br><div class="gmail_quote">2011/4/28 Jonas Smedegaard <span dir="ltr"><<a href="mailto:dr@jones.dk">dr@jones.dk</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11-04-28 at 08:00pm, Edvin Dunaway wrote:<br>
> yes, I agree.<br>
> we need to settle on what will be in that tarball and as well create a<br>
> reposatory for git-buildpackage; BRE: I'll contact you tomorrow about<br>
> it. I've been looking into it and so far it's been quite straight<br>
> forward, though I'm still getting used to git.<br>
> the documentation that I've been reading is here:<br>
> <a href="http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html" target="_blank">http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html</a><br>
><br>
> Jonas: any hints, ideas or specifications on your behalf?<br>
<br>
</div>Above looks like the official documentation for git-buildpackage.<br>
That's a good read, but beware that it covers several ways to use the<br>
tool, not necessarily the most common or the one currently best<br>
integrated with other packaging tools. Have a look here as well - that<br>
seems (from a quick glance) to better cover that other end of the scale:<br>
<a href="http://wiki.debian.org/PackagingWithGit" target="_blank">http://wiki.debian.org/PackagingWithGit</a><br>
<br>
Regarding upstream tarball releases: The description on your code being<br>
all contained in a single script unfolding itself automagically and<br>
therefore not needing common things like config file or documentation,<br>
really really worries me! That might be cool when you serve the code<br>
directly to your end-users, but un-cool when distributed by e.g. Debian.<br>
<br>
Commonly sysadmins are conservative - hate it when scripts try to be<br>
clever. Distributors are even more conservative - if needing to later<br>
change a comma in the script e.g. due to a security bug, thousands or<br>
millions of users may be affected and not expect an already installed<br>
tool to change behaviour *at* *all* during a stable security update.<br>
Tools should be reliable, not clever. Not create config files<br>
automagically, but contain sensible internal defaults and/or fail if<br>
crucial config info is missing.<br>
<br>
So I stringly urge you to revisit how you design your tool. To store<br>
boring old-style config files separately, to include a README containing<br>
runtime usage info, an INSTALL document containing setup info, and a man<br>
page containing more or less the same as the README but in a very strict<br>
composition. And so on and so on. Basically: Look at how others ship<br>
code, and mimick most possible of that, instead of trying to be smarter!<br>
<br>
<br>
Edvin: I recommend to avoid the "digest" mode of subscription to the<br>
mailinglist, as that disrupts the naming of threads. :-)<br>
<br>
<br>
<br>
Kind regards,<br>
<div><div></div><div class="h5"><br>
- Jonas<br>
<br>
--<br>
* Jonas Smedegaard - idealist & Internet-arkitekt<br>
* Tlf.: <a href="tel:%2B45%2040843136" value="+4540843136">+45 40843136</a> Website: <a href="http://dr.jones.dk/" target="_blank">http://dr.jones.dk/</a><br>
<br>
[x] quote me freely [ ] ask before reusing [ ] keep private<br>
</div></div><br>_______________________________________________<br>
Pkg-pagekite-devel mailing list<br>
<a href="mailto:Pkg-pagekite-devel@lists.alioth.debian.org">Pkg-pagekite-devel@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/mailman/listinfo/pkg-pagekite-devel" target="_blank">http://lists.alioth.debian.org/mailman/listinfo/pkg-pagekite-devel</a><br>
<br></blockquote></div><br>