Re: RFS: Folding@home
Nick Lewycky [EMAIL PROTECTED] wrote: 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.) Don't ask me... Well, perhaps route can do the trick. I'm not sure, but I think even in a non-connected dialup system there has to be some connection between the default route and the to-be connection. On an ISDN system, there's a network device up even if not connected, but I'm not sure for normal ppp connections. - 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. [...] I don't get it. What would you want it to do if you ran it from the commandline? Well, e.g. -queueinfo would be interesting, -verbosity might be useful, -forceSSE or -forceasm might be better on certain systems, etc. 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. That's bad. But one could create a wrapper script in /usr/bin #!/bin/sh FAHDIR=/var/lib/folding EXECUTABLE=ForgotTheFancyName cd $FAHDIR $EXECUTABLE $* 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. So the wrapper would have to change it's UID - probably a case for a perl script. I don't have any experience with such stuff, but there was a discussion on this a while ago here in the group. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: RFS: Folding@home
Nick Lewycky [EMAIL PROTECTED] wrote: 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.) Don't ask me... Well, perhaps route can do the trick. I'm not sure, but I think even in a non-connected dialup system there has to be some connection between the default route and the to-be connection. On an ISDN system, there's a network device up even if not connected, but I'm not sure for normal ppp connections. - 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. [...] I don't get it. What would you want it to do if you ran it from the commandline? Well, e.g. -queueinfo would be interesting, -verbosity might be useful, -forceSSE or -forceasm might be better on certain systems, etc. 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. That's bad. But one could create a wrapper script in /usr/bin #!/bin/sh FAHDIR=/var/lib/folding EXECUTABLE=ForgotTheFancyName cd $FAHDIR $EXECUTABLE $* 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. So the wrapper would have to change it's UID - probably a case for a perl script. I don't have any experience with such stuff, but there was a discussion on this a while ago here in the group. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: RFS: Folding@home
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,
Re: RFS: Folding@home
Frank Küster wrote: 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
Re: RFS: Folding@home
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,
Re: RFS: Folding@home
Frank Küster wrote: 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.
Re: RFS: Folding@home
Nick Lewycky [EMAIL PROTECTED] wrote: 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 [...] [EMAIL PROTECTED] is only distributed in binary form from Stanford's official webserver. This package will download the client from Stanford and install it on your computer. It is only available for x86. This is an install package, intended for contrib/misc alongside packages like setiathome which do the same thing for another project. I think you should name it [EMAIL PROTECTED], then. And it needs a proper license, too. Ah, I just noticed that you named the package folding. I'd really choose a longer name. I would have to look up if @ is a valid character in a package name, but you can always use at instead. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: RFS: Folding@home
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. - there's a superfluous templates.pot in the top-level directory - I'm not sure, but is it common practice to put installer packages for non-free software into contrib? - 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. - you should remove commented lines and unnecessary targets from debian/rules. - 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? - the stale links in /var/log seem odd. - 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. - 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. - 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. - please see the recent thread here in the group about name-group-separators for chown. - the #DEBHELPER# entry inside an if-statement seems to be wrong. Oh, I see, you repeat it later. Hm. still it seems odd. - 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. - 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. 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. 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] 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. ` Have you checked (without a proxy)? Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: RFS: Folding@home
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? 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
Re: RFS: Folding@home
Nick Lewycky [EMAIL PROTECTED] wrote: 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 [...] [EMAIL PROTECTED] is only distributed in binary form from Stanford's official webserver. This package will download the client from Stanford and install it on your computer. It is only available for x86. This is an install package, intended for contrib/misc alongside packages like setiathome which do the same thing for another project. I think you should name it [EMAIL PROTECTED], then. And it needs a proper license, too. Ah, I just noticed that you named the package folding. I'd really choose a longer name. I would have to look up if @ is a valid character in a package name, but you can always use at instead. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: RFS: Folding@home
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. - there's a superfluous templates.pot in the top-level directory - I'm not sure, but is it common practice to put installer packages for non-free software into contrib? - 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. - you should remove commented lines and unnecessary targets from debian/rules. - 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? - the stale links in /var/log seem odd. - 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. - 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. - 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. - please see the recent thread here in the group about name-group-separators for chown. - the #DEBHELPER# entry inside an if-statement seems to be wrong. Oh, I see, you repeat it later. Hm. still it seems odd. - 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. - 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. 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. 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] 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. ` Have you checked (without a proxy)? Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: RFS: Folding@home
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? 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
RFS: Folding@home
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 Long description: [EMAIL PROTECTED] performs research by simulating the folding processes of proteins, RNA and synthetic polymers. The results of the simulations are sent to Stanford University who release them to the biochemical community. Protien misfoldings are implicated in diseases such as Alzheimer's, cyctic fibrosis and others. By contributing, your computers' idle time will work towards an understanding of these diseases. [EMAIL PROTECTED] is only distributed in binary form from Stanford's official webserver. This package will download the client from Stanford and install it on your computer. It is only available for x86. This is an install package, intended for contrib/misc alongside packages like setiathome which do the same thing for another project. I spent the past 3 days cooking up a package and testing it. It appears to work perfectly, fingers crossed. I haven't tested it exhaustively yet, but upgrades, downgrades, installs, removals and purging all work. I'm seeking feedback about my packaging job. Although I've made packages for internal use, this is my first package released to the public. Please let me know if I made any mistakes, or also if you did look at it and couldn't find any. In the same vein, if you are an experienced DD and decide that the package is ready for the archive, I'd appreciate if you would sponsor it for me. Again, the URL to download it from is http://wagon.dhs.org/folding/ Thanks, Nick Lewycky
RFS: Folding@home
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 Long description: [EMAIL PROTECTED] performs research by simulating the folding processes of proteins, RNA and synthetic polymers. The results of the simulations are sent to Stanford University who release them to the biochemical community. Protien misfoldings are implicated in diseases such as Alzheimer's, cyctic fibrosis and others. By contributing, your computers' idle time will work towards an understanding of these diseases. [EMAIL PROTECTED] is only distributed in binary form from Stanford's official webserver. This package will download the client from Stanford and install it on your computer. It is only available for x86. This is an install package, intended for contrib/misc alongside packages like setiathome which do the same thing for another project. I spent the past 3 days cooking up a package and testing it. It appears to work perfectly, fingers crossed. I haven't tested it exhaustively yet, but upgrades, downgrades, installs, removals and purging all work. I'm seeking feedback about my packaging job. Although I've made packages for internal use, this is my first package released to the public. Please let me know if I made any mistakes, or also if you did look at it and couldn't find any. In the same vein, if you are an experienced DD and decide that the package is ready for the archive, I'd appreciate if you would sponsor it for me. Again, the URL to download it from is http://wagon.dhs.org/folding/ Thanks, Nick Lewycky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
