Nick Lewycky <[EMAIL PROTECTED]> schrieb: > First off, I'd like to thank you for spending the time to construct > this useful analysis! > > 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?
The software that you are packaging is not the software that has the version number 4.00. [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: > [...] > 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] 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 [EMAIL PROTECTED] It's an installer package, and it can (it must) be installable without the actual [EMAIL PROTECTED] being present. If any of the 3rd party utilities is going to be packaged for Debian, it will have to Depend on a [EMAIL PROTECTED] 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 [EMAIL PROTECTED] being actually on the system. Or they have to rely on a [EMAIL PROTECTED] 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 "[EMAIL PROTECTED]", 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
