Nick Lewycky <[EMAIL PROTECTED]> schrieb:
Frank Küster wrote:
Nick Lewycky <[EMAIL PROTECTED]> schrieb:
Package name : folding Version : 4.00 Upstream : http://folding.stanford.edu URL : http://wagon.dhs.org/folding/ Description : [EMAIL PROTECTED] 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 [EMAIL PROTECTED], 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
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
