Re: Documentation for upstream software authors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian 'Dagurashibanipal' von Bidder wrote: I've just started http://wiki.debian.net/SoftwarePackaging, intended to collect thoughts of packagers how upstream developers can make the life of a packager easier. I'm sure all packagers have wondered about brain-dead upstream developers who have not put much thought into how their software might be distributed in a pre-compiled/pre-configured package. Compile-time options are one example, user-modifiable files outside of /etc are another, to name the two that I could think of just now. Hi Adrian, I wrote something vaguely similar after getting frustrated at a number of problems with free (either as in beer or speech) physics software. Maybe you can find something useful in it: http://www.princeton.edu/~kmccarty/physics-software-rant.html In case you need a licensing statement, I hereby license the entire contents of that HTML file (not including images or CSS) under the BSD license (found in /usr/share/common-licenses/BSD on a Debian system), substituting my name for The Regents of the University of California and the University. regards, - -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBmssyfYxAIk+Dx1ERAg+bAJwOare2Jn0jF9YAJS4lnFKquIakRACg0Jxo kIpVjqHfCyVI2BS3mOyK2ys= =Va1v -END PGP SIGNATURE-
Re: Documentation for upstream software authors
On Sunday 14 November 2004 21.55, Martin Pitt wrote: Martin Schulze [2004-11-14 20:13 +0100]: [...] Thanks for your comments, I believe I have covered all that now. cheers -- vbi (And: hey, it's a wiki, do it yourself :-) -- Oops pgpMIDf03LZ1t.pgp Description: PGP signature
Re: Documentation for upstream software authors
Adrian 'Dagurashibanipal' von Bidder wrote: I've just started http://wiki.debian.net/SoftwarePackaging, intended to collect thoughts of packagers how upstream developers can make the life of a packager easier. I'm sure all packagers have wondered about brain-dead upstream developers who have not put much thought into how their software might be distributed in a pre-compiled/pre-configured package. Compile-time options are one example, user-modifiable files outside of /etc are another, to name the two that I could think of just now. What comes to my mind: - public version control (cvs, arch, svn) by upstream - public development mailing list - public availability of old and new versions at a defined location (for watch files etc.) - clean clean target - don't distribute auto-generated files except for configure/autofoo but add rules to the Makefile to generate them on-demand - add a private mail address of the lead developer to the distributed files (contrary to only a mailing list, this is important for security problems that need to be discussed off the public first) - configurability of path names (so that the pkg can be made FHS compatible easily without loads of patches) - an announce list and a packager list may also be helpful to notify packages of new versions / security problems (private) Regards, Joey -- Testing? What's that? If it compiles, it is good, if it boots up, it is perfect. Please always Cc to me when replying to me on the lists.
Re: Documentation for upstream software authors
Hi! Martin Schulze [2004-11-14 20:13 +0100]: Adrian 'Dagurashibanipal' von Bidder wrote: I've just started http://wiki.debian.net/SoftwarePackaging, intended to collect thoughts of packagers how upstream developers can make the life of a packager easier. I'm sure all packagers have wondered about brain-dead upstream developers who have not put much thought into how their software might be distributed in a pre-compiled/pre-configured package. Compile-time options are one example, user-modifiable files outside of /etc are another, to name the two that I could think of just now. What comes to my mind: - public version control (cvs, arch, svn) by upstream - public development mailing list - public availability of old and new versions at a defined location (for watch files etc.) - clean clean target - don't distribute auto-generated files except for configure/autofoo but add rules to the Makefile to generate them on-demand - add a private mail address of the lead developer to the distributed files (contrary to only a mailing list, this is important for security problems that need to be discussed off the public first) - configurability of path names (so that the pkg can be made FHS compatible easily without loads of patches) - an announce list and a packager list may also be helpful to notify packages of new versions / security problems (private) - Refrain from including source code from libraries which are externally available, or at least make it easy to use the external version of a library instead. Half a thousand copies of one and the same library scattered throughout Debian is an outright security nightmare. Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Documentation for upstream software authors
[list policy is not to send cc:s - thank you] On Tuesday 09 November 2004 17.00, Frank Küster wrote: Please do not use language like brain-dead in the text of this page. Right - and you're too late, was already removed. An other point could be Use sensible version numbering: added, thanks. greetings -- vbi -- Oops pgpMr0HMGt7yc.pgp Description: PGP signature
Re: Documentation for upstream software authors
Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] schrieb: Hi, I've just started http://wiki.debian.net/SoftwarePackaging, intended to collect thoughts of packagers how upstream developers can make the life of a packager easier. The idea sounds good. However, I'm sure all packagers have wondered about brain-dead upstream developers who have not put much thought into how their software might be distributed in a pre-compiled/pre-configured package. Please do not use language like brain-dead in the text of this page. What will an upstream developer think if I point him to a page with some useful information and he finds himself called brain-dead - by you and, because I told him to read it, by me? An other point could be Use sensible version numbering: - Most importantly, take care that newer versions have a higher value in alphanumeric comparisons than older versions. I know a project where 0.92-1, 0.92-2, 0.92-3 were the release candidates for 0.92... - Make clear which version numbers correspond to development versions/branches, and which are for releases - Make clear which versions indicate a major release, and which only a bugfix release (if the project was first released with 0.1, and had 0.2, 0.3... afterwards, then 1.0 to 1.1 is probably a major release, not just a bugfix release of 1.0) Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
