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?
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"?
- there's a superfluous templates.pot in the top-level directory
Thanks. I'll fix that RSN.
- I'm not sure, but is it common practice to put installer packages for
non-free software into contrib?
The "distributed-net" package is in non-free while the "setiathome" package is in contrib. A concensus would be a good thing here. From my reading, contrib is correct.
- debian/copyright: You HAVE TO have a copyright statement for the code that you wrote in the installer package, and it has to be have DFSG-free license to be able to go into contrib or main. It's probably a good idea to also include upstreams license, but NOT in the copyright file of your package.
Thanks. I'll fix that too.
- you should remove commented lines and unnecessary targets from
debian/rules.
Ok.
- your postinst seems to write into files "client.cfg" in the current
directory. This is bad - there might be other files there with the
same name. Later you repeat it in /var/lib/folding - why the
duplication?
It's not supposed to be in the current directory, the error is that I was missing "cd /var/lib/folding" inside of the if.
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.
- 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.
- It seems that the main work of the package is done in the postinst. I
would suggest that you put this into a separate script, with the
option to call it from postinst, or to delay that to a later
timepoint. If this is included in Debian, people will chose it in
their first big "Ah, now let's look what cool packages are on those
disks" install run, and then it's annoying to see the modem dialling
in postinst to get that file, while in fact you are eager to test all
the cool stuff you just selected. And there may be no network
connection at all during installation.
(Refer to "I see a theme here..." below.)
- the postinst calls /etc/init.d/folding restart before the user is created (reconfigure may be called after the user account has been accidently deleted!). That will either not work, or have unexpected consequences.
No it doesn't. Notice that there's an "exit 0" right afterwards? That's the reconfiguration-only branch of the code. (By which I mean a manual run of dpkg-reconfigure which implies that configuration (the installation step) has already occured.)
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.
- I doubt that "folding" is a good name for the user. The name may be in use for a local user who owns group-public protein folding data.
That's a general problem which can occur with any name I choose, or with other packages. I'd be willing to go for "fahclient" as a username, but not "foldingathome", "fahlinux", "[EMAIL PROTECTED]" or most variants. I like "folding" since it fits within the username column as displayed by top.
- please see the recent thread here in the group about name-group-separators for chown.
Thanks. Fixed.
- the #DEBHELPER# entry inside an if-statement seems to be wrong. Oh, I see, you repeat it later. Hm. still it seems odd.
Right after #DEBHELPER# is "exit 0" so what I'm doing here is making certain that #DEBHELPER# happens before I exit. The inside of that if is the standard upgrade case where the client on disk matches the md5sum on the package and there's no reason to download a new one.
- 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.
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?
- 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! :)
I would advice not to make a Debian-native package of this. It's quite
simple, and it can as well be used on an rpm-based distribution, without
modification of the main script (postinst) - therefore other
distributions might re-use it.
Ok, I'll change that.
Furthermore, I think that an installer package is only really useful if
it creates a Debian package out of the downloaded stuff - that's the
whole point of a package managment. Although, I admit, I cannot
currently imagine a program that would want to depend on [EMAIL PROTECTED]
There are 3rd party utilities for [EMAIL PROTECTED]:
fpd & qd: http://boston.quik.com/rph/fah.html
qdcsv: http://homepage.mac.com/iam_kranki2/qdcsv.html
KFoldingApplet: http://home.houston.rr.com/epasveer/
kfolding: http://members.shaw.ca/khessels/kfolding/
KFold monitor: http://www.kdfold.com/
... and others.
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 [EMAIL PROTECTED] If you remove it, you remove [EMAIL PROTECTED]
(Note that your suggestion that I move the install out of postinst breaks this illusion slightly. I'll have to wait until this time tommorow before I decide how I feel about that.)
One other question: The following text on the website makes me think that your md5sum check will always fail:
,---- | Each different running copy of [EMAIL PROTECTED] has to have its own Machine ID | number. If you download each copy of [EMAIL PROTECTED] from the web site and install | fresh, there will be no problems. `----
No, the client creates "machinedependent.dat" in the current working directory the first time it is run. The downloaded file is always the same.
Have you checked (without a proxy)?
Actually I have. What I haven't checked is *with* a proxy since it would take me a while to set up a proxy just to test my package on. I'd really appreciate if someone else would test that for me.
I'm going to make the remaining changes and upload new packages soon. Thanks a lot for your comments!
Nick Lewycky
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
