Bug#252101: ITP: gromacs -- versatile package to perform molecular dynamics
On Sun, 6 Nov 2005, Nicholas Breen wrote: 1. Did you consider putting the changes you do to upstream into seperate patches, maintained in a debian/patches directory via a patch-system like dpatch or quilt? Didn't seem necessary. Nearly the entire set of patches relates to documentation changes or additions that I'm pushing upstream, which should shrink the non-debian-specific components of the diff to nearly nothing if they're accepted. Well, perhaps dpatch just helps you to maintain your own stuff so perhaps you should consider it anyway. The reason for the Debian-specific name is to make it blindingly obvious that it's a change from upstream. Because scientific software demands reproducibility, the authors prefer it if all changes from the upstream source are clearly marked; You are right that it should be clearly marked, but this should be done in a README.Debian file or somewhere else in the documentation and not really in a version number change. Splitting off -doc packages is always something of a judgment call between space efficiency and Packages.gz bloat. I'm personally a very big friend of splitting up large documentation from the binary package. The total of /usr/share/doc/gromacs and /usr/share/gromacs/tutor (the tutorial files) is only 4.3MB, out of a total installed size of ~16MB. Since this isn't that much of a savings, I decided it wasn't worth splitting off a separate -doc package. Well, I would consider every documentation above 0,5MB worth splitting up and in your case it is 25% which is definitely worth the effort. Especially if you think of binary packages for 12 architectures that copy architecture independant stuff into their mirrors. I am certainly amenable to team maintenance, and am greatly interested in assisting with other chemistry software. I'm not a DD, and do need a sponsor for the package. I've asked Andreas Tille (cc:'d on this message) already, but he sounds fairly busy at the moment -- perhaps the two of you could discuss that? I would prefer if somebody else would take over the sponsoring but would be serve as a fallback if nobody steps in. Kind regards Andreas. -- Wenn durch das Land die Grippe saust, es meiner ganzen Sippe graust. http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#252101: ITP: gromacs -- versatile package to perform molecular dynamics
On Sat, Nov 05, 2005 at 12:42:04PM +0100, Michael Banck wrote: > I took a look at your gromacs package as I accidently found the ITP. > I've been trying to package gromacs for a couple of years now, so I am > glad I checked before just uploading something :) > > Anyway, I played around with your package a bit and got some questions: > > 1. Did you consider putting the changes you do to upstream into seperate > patches, maintained in a debian/patches directory via a patch-system > like dpatch or quilt? Didn't seem necessary. Nearly the entire set of patches relates to documentation changes or additions that I'm pushing upstream, which should shrink the non-debian-specific components of the diff to nearly nothing if they're accepted. > 2. When you modify configure, why do you not change configure.in > accordingly? I believe we should rather patch configure.in and > regenerate configure (possibly removing unneeded noise in the diff). > Did you consider sending your modifications upstream, possible making > them more generic (like ${MPI_LIBSUFFIX}) I'm sure I had some reason for not editing configure.in when I did it, but I cannot for the life of me remember what that reason was. You're right that it should hold the patch rather than configure. The reason for the Debian-specific name is to make it blindingly obvious that it's a change from upstream. Because scientific software demands reproducibility, the authors prefer it if all changes from the upstream source are clearly marked; I doubt that particular change will affect anyone, but it doesn't hurt to highlight it. I will be sending that patch upstream as well with a more generic name. > 3. Did you consider making a gromacs-doc package including the manual? > I think it bloats up the Debian diff rather considerably. Alos, you got > the manual from www.gromacs.org, right? Did you clarify whether the > copyright is the same as for the program or something else? The .pdf is the big killer in the .diff at the moment; as mentioned, all the other doc changes are heading upstream. The authors of the .pdf manual have informed me that it's licensed under the GPL, identically with the rest of the package. Splitting off -doc packages is always something of a judgment call between space efficiency and Packages.gz bloat. The total of /usr/share/doc/gromacs and /usr/share/gromacs/tutor (the tutorial files) is only 4.3MB, out of a total installed size of ~16MB. Since this isn't that much of a savings, I decided it wasn't worth splitting off a separate -doc package. > 4. Finally, would you consider maintaining gromacs as part of a > hopefully-soon-to-be-started Debian-chemistry-packaging-team effort from > svn.debian.org? Are you a Debian Developer? If not, do you need > sponsoring? I am certainly amenable to team maintenance, and am greatly interested in assisting with other chemistry software. I'm not a DD, and do need a sponsor for the package. I've asked Andreas Tille (cc:'d on this message) already, but he sounds fairly busy at the moment -- perhaps the two of you could discuss that? -- Nicholas Breen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#252101: ITP: gromacs -- versatile package to perform molecular dynamics
Hi, I took a look at your gromacs package as I accidently found the ITP. I've been trying to package gromacs for a couple of years now, so I am glad I checked before just uploading something :) Anyway, I played around with your package a bit and got some questions: 1. Did you consider putting the changes you do to upstream into seperate patches, maintained in a debian/patches directory via a patch-system like dpatch or quilt? 2. When you modify configure, why do you not change configure.in accordingly? I believe we should rather patch configure.in and regenerate configure (possibly removing unneeded noise in the diff). Did you consider sending your modifications upstream, possible making them more generic (like ${MPI_LIBSUFFIX}) 3. Did you consider making a gromacs-doc package including the manual? I think it bloats up the Debian diff rather considerably. Alos, you got the manual from www.gromacs.org, right? Did you clarify whether the copyright is the same as for the program or something else? 4. Finally, would you consider maintaining gromacs as part of a hopefully-soon-to-be-started Debian-chemistry-packaging-team effort from svn.debian.org? Are you a Debian Developer? If not, do you need sponsoring? cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]