Re: RFS: Folding@home
Nick Lewycky <nicholas@mxc.ca> schrieb:
> First off, I'd like to thank you for spending the time to construct
> this useful analysis!
>
> 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?
The software that you are packaging is not the software that has the
version number 4.00. Folding@Home has Version number 4.00, but it may
not be redistributed. The software you are trying to make a Debian
package of is an installer for Folding@Home. I see no reason why it
should have the same version number as the software it wants to
install.
> I'd also like to avoid long package names which don't fit in the first
> column of "dpkg --list". I also want the package name to match the
> username it creates. How about "fahclient"?
That would be okay for me.
> The reason for the duplication is simple. That test is for whether
> this package is currently being reconfigured. Not to be confused with
> configuration, which happens on first install only. We don't want to
> rerun adduser on reconfigure.
I would suggest to do a more structured programming. That is, define a
shell function "make_clientcfg" or the like, which can be called upon
first installation or upgrade as well as upon reconfigure. Then you have
a single point where you can make (and forget...) changes.
>> - the stale links in /var/log seem odd.
>
> That's because they are!
>
> It's a wart. FAH4Console-Linux.exe outputs FAHlog.txt in its working
> directory. It also manages its own log rotation into
> FAHlog-Prev.txt. I decided that links to these files in /var/log was
> the best way to comply with Debian Policy section 10.8.
Okay, I didn't know that. Looks like a solution.
> 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.
>> - You REALLY shouldn't let the postinst fail if the download
>> fails. Nobody will be able to fix and finish the installation (of your
>> and other packages) if the internet connection, or maybe just the
>> proxy is down.
>
> I see a theme here: you want to seperate the installer package
> installation from the downloading step. I find that a bit awkward
> myself, but then I'm always online.
You're right that I'd prefer that, but _this_ is not a question of
taste, it would be a real bug. There are many Debian users who are not
always online. Even if Folding@Home cannot properly be configured for a
dialup connection (I think it can), your package must not break people's
systems if they install it just to have a look at it.
> 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.
On the other hand, I don't know how big the exe file is.
>> - 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.
> There are 3rd party utilities for Folding@home:
>
[...]
> As for creating a package out of the downloaded content, there's no
> benefit to doing that. The installer package is a proxy for the real
> thing. If you install it, you get Folding@home.
Except if you're installing while offline, or while your proxy is down,
or whatever. As I said above in the discussion about versions: No, in my
opinion the Debian package we are speaking about is NOT
folding@home. It's an installer package, and it can (it must) be
installable without the actual folding@home being present. If any of the
3rd party utilities is going to be packaged for Debian, it will have to
Depend on a folding@home package. Either they depend on your package, as
it currently is - then you'll get RC bug reports once people notice that
they cannot rely on folding@home being actually on the system. Or they
have to rely on a folding@home package made from the downloaded stuff.
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.
> (Note that your suggestion that I move the install out of postinst
> breaks this illusion slightly.
I would say it breaks your illusion that your package is "folding@home",
and makes clear that it isn't.
> 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?
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Reply to: