Re: RFS: Folding@home
Frank Küster wrote:
Nick Lewycky <nicholas@mxc.ca> schrieb:
Frank Küster wrote:
Nick Lewycky <nicholas@mxc.ca> schrieb:
Package name : folding
Version : 4.00
Upstream : http://folding.stanford.edu
URL : http://wagon.dhs.org/folding/
Description : Folding@home Client (install package)
WNPP bug : http://bugs.debian.org/261257
Some further remarks:
- Why is the version 4.00? If this is the version of the upstream
software, I would rather name the package folding@home4-installer, or
- if it doesn't matter - omit this version completely, and just give
it its own versioning.
The upstream version is 4.00. Moving the 4 to the package name is
wrong and will break upgrades to version 5 some day. Removing the
version from the package version is sub-optimal (but permissible) by
Debian Policy, section 3.2.1. Is there a compelling reason to remove
it?
Well, now that we've decided that the installer isn't a proxy for the
package, I guess I'll renumber it. How about fahclient-0.0.0+pre0.0.1? ;-)
I'll grant that the logic throughout postinst is highly
convoluted. Does POSIX sh support functions? I avoided them in case
they are a bash-ism, but if not, they would allow me to greatly
clarify the workings of postinst.
According to SUSV2 (http://www.opengroup.org/onlinepubs/007908799/) it
does.
Awesome. I'll update the packages once I get the package-building trick
to work, likely before Monday.
Would it be ok if it tried to download, failed gracefully (allowing
the package to install) by offering a script that would perform the
installation manually? And online users would see it work
automatically with no intervention?
That would be okay in the sense that the bug would be fixed. But I
wouldn't like it - I would at least want a debconf question (with
default no, of course, for noninteractive installation) whether the
download should be in the postinst phase.
If there any sane way to autodetect a network connection? I'm strongly
adverse to hassling anybody with extra debconf questions.
I'll agree to a debconf question for it only if there's no good way to
handle online and offline cases automatically. (This includes systems
that might be set up to dial on outgoing connection attempts. However it
detects the network should not trigger such a mechanism.)
On the other hand, I don't know how big the exe file is.
276,740 bytes.
- there's no documentation. At least you should try to (get permission
to) include the command line options in
http://folding.stanford.edu/console-userguide.html.
Hm, that's because you're not supposed to run it directly. You're
supposed to let it add itself into your runlevels and work away. Keep
those filthy hands off! :)
That's not Debian philosophy. Of course it is nice if a program runs
just out-of-the box. But if it does have command line switches (and
folding seems to have lots of them), you should document them. If you
don't get permission, rewrite the text from scratch.
BTW, a binary without a manpage is a bug. You only escape this because
you put it in /var/lib, but the missing symlink from /usr/bin might be
regarded as a separate bug.
I don't get it. What would you want it to do if you ran it from the
commandline?
It will try to prevent you from starting two running clients, with some
exceptions (see Machine ID numbers).
If you do manage to get it running, it will proceed to download a new
"machinedependent.dat", create a "queue" directory, download its
FahCore*.exe files, and leave all this crap in the directory you ran it
from. Not pretty.
You can't reconfigure it, since you aren't running it as the "fahclient"
user in the /var/lib/fahclient directory. You can't ask it for its queue
information for the same reason.
I don't mind documenting it to help users modify /etc/init.d/fahclient
if they like, but a symlink in /usr/bin is just plain wrong.
I have once written an installer package that creates a Debian package,
for molscript. It never was published, but if you like I can send you
the files. That were my first experiments with Debian packages, probably
with many errors in them, but the principle should work.
Thanks for the offer, but I already have reference material to work from.
No, the client creates "machinedependent.dat" in the current working
directory the first time it is run. The downloaded file is always the
same.
Ahem? So a dialup system that downloads the file with one IP number, but
contacts the server with another one (possibly used yet by an other
client), will get problems? Or is the connection between "download from
here" and unique identification just FUD?
Just FUD. Imagine that the client, on first run, contacts the server
saying "Hey! I'm a new install!" and the server runs "uuidgen" and sends
back a "machine number" for future reference.
The downloading step is entirely, entirely, entirely disconnected from
the future operations of the client.
Nick Lewycky
Reply to: