[Freedos-devel] freedos package spec problem: sources, binary, docs
Hi all, Blair pointed me to the fact that source packages are not supposed to contain docs, according to our specs. I object that recommendation. In my opinion, source packages should contain everything outside the bin directory, and binary packages should contain everything outside the source directory. My reason for this recommendation is that end users should have all documentation and that all documen- tation in fact IS part of the source code. When we work on updating a program, it has to be sufficient to download ONLY the source package to create a new version of the full binary package. One might say that this wastes space in situations where you put both source and binary package zips in one directory. Well. Shit happens. Or if that is not acceptable, one could put MINIMAL SOURCE zip packages in that directory, containing ONLY the source directory contents. Along with a readme which tells that the source zips in that directory can only be used in combination with the binary zips. Source packages which are available via http should contain the full docs. This avoids two problems: - people would otherwise have to download the old exe even if they only wanted the docs, for example for creating derived versions of the sources - programmers would otherwise easily forget to update the docs or, even worse, the NLS files when they modify the source code An alternative solution for all the hassles might be to have the docs in a third zip. Then you would have to download 2 of 3 zips for development and 2 of 3 zips for using the program. And all 3 zips would have minimal size. If anybody cares for size of source packages. Still I would really prefer to have all docs in the source zips! After all, people usually download only the sources of SELECTED packages. And the open source idea tells me that the sources are the origins of the world, so it should not be necessary to download the binary package to understand the sources. Eric - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freedos package spec problem: sources, binary, docs
I think you are referring to this mini-HOWTO: http://fd-doc.sourceforge.net/wiki/index.php?n=FdDocEn.Distribution Yes, I agree that the source package should contain everything short of the generated binaries. If there are dupe files, let them be overwritten. This mini-HOWTO needs to be updated to say that. -jh Eric Auer wrote: Hi all, Blair pointed me to the fact that source packages are not supposed to contain docs, according to our specs. I object that recommendation. In my opinion, source packages should contain everything outside the bin directory, and binary packages should contain everything outside the source directory. My reason for this recommendation is that end users should have all documentation and that all documen- tation in fact IS part of the source code. When we work on updating a program, it has to be sufficient to download ONLY the source package to create a new version of the full binary package. One might say that this wastes space in situations where you put both source and binary package zips in one directory. Well. Shit happens. Or if that is not acceptable, one could put MINIMAL SOURCE zip packages in that directory, containing ONLY the source directory contents. Along with a readme which tells that the source zips in that directory can only be used in combination with the binary zips. Source packages which are available via http should contain the full docs. This avoids two problems: - people would otherwise have to download the old exe even if they only wanted the docs, for example for creating derived versions of the sources - programmers would otherwise easily forget to update the docs or, even worse, the NLS files when they modify the source code An alternative solution for all the hassles might be to have the docs in a third zip. Then you would have to download 2 of 3 zips for development and 2 of 3 zips for using the program. And all 3 zips would have minimal size. If anybody cares for size of source packages. Still I would really prefer to have all docs in the source zips! After all, people usually download only the sources of SELECTED packages. And the open source idea tells me that the sources are the origins of the world, so it should not be necessary to download the binary package to understand the sources. Eric -- This email message has been encrypted using the ROT-26 cipher. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freedos package spec problem: sources, binary, docs
Two small notes: (1) The HELP file (for FASTHELP) is probably NOT required in the source package either (2) There are docs that are very specific to sources (e.g. how to build and such), that I myself usually don't pack under DOC, but under SRC\DOC, so that they are only installed with sources (I don't know if I'm doing it well). Aitor PS: Jim, I don't know if you read my message from private mail: I was just trying to ask you if you could allow or invite me to write to you private messages from this account of mine (gmail). I say this as I know your university seemed to have an ellaborate way of granting access to you ;-) 2006/8/28, Jim Hall [EMAIL PROTECTED]: I think you are referring to this mini-HOWTO: http://fd-doc.sourceforge.net/wiki/index.php?n=FdDocEn.Distribution Yes, I agree that the source package should contain everything short of the generated binaries. If there are dupe files, let them be overwritten. This mini-HOWTO needs to be updated to say that. -jh Eric Auer wrote: Hi all, Blair pointed me to the fact that source packages are not supposed to contain docs, according to our specs. I object that recommendation. In my opinion, source packages should contain everything outside the bin directory, and binary packages should contain everything outside the source directory. My reason for this recommendation is that end users should have all documentation and that all documen- tation in fact IS part of the source code. When we work on updating a program, it has to be sufficient to download ONLY the source package to create a new version of the full binary package. One might say that this wastes space in situations where you put both source and binary package zips in one directory. Well. Shit happens. Or if that is not acceptable, one could put MINIMAL SOURCE zip packages in that directory, containing ONLY the source directory contents. Along with a readme which tells that the source zips in that directory can only be used in combination with the binary zips. Source packages which are available via http should contain the full docs. This avoids two problems: - people would otherwise have to download the old exe even if they only wanted the docs, for example for creating derived versions of the sources - programmers would otherwise easily forget to update the docs or, even worse, the NLS files when they modify the source code An alternative solution for all the hassles might be to have the docs in a third zip. Then you would have to download 2 of 3 zips for development and 2 of 3 zips for using the program. And all 3 zips would have minimal size. If anybody cares for size of source packages. Still I would really prefer to have all docs in the source zips! After all, people usually download only the sources of SELECTED packages. And the open source idea tells me that the sources are the origins of the world, so it should not be necessary to download the binary package to understand the sources. Eric -- This email message has been encrypted using the ROT-26 cipher. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freedos package spec problem: sources, binary, docs
I agree with Aitor. On 8/27/06, Aitor Santamaría [EMAIL PROTECTED] wrote: Two small notes: (1) The HELP file (for FASTHELP) is probably NOT required in the source package either (2) There are docs that are very specific to sources (e.g. how to build and such), that I myself usually don't pack under DOC, but under SRC\DOC, so that they are only installed with sources (I don't know if I'm doing it well). Aitor PS: Jim, I don't know if you read my message from private mail: I was just trying to ask you if you could allow or invite me to write to you private messages from this account of mine (gmail). I say this as I know your university seemed to have an ellaborate way of granting access to you ;-) 2006/8/28, Jim Hall [EMAIL PROTECTED]: I think you are referring to this mini-HOWTO: http://fd-doc.sourceforge.net/wiki/index.php?n=FdDocEn.Distribution Yes, I agree that the source package should contain everything short of the generated binaries. If there are dupe files, let them be overwritten. This mini-HOWTO needs to be updated to say that. -jh Eric Auer wrote: Hi all, Blair pointed me to the fact that source packages are not supposed to contain docs, according to our specs. I object that recommendation. In my opinion, source packages should contain everything outside the bin directory, and binary packages should contain everything outside the source directory. My reason for this recommendation is that end users should have all documentation and that all documen- tation in fact IS part of the source code. When we work on updating a program, it has to be sufficient to download ONLY the source package to create a new version of the full binary package. One might say that this wastes space in situations where you put both source and binary package zips in one directory. Well. Shit happens. Or if that is not acceptable, one could put MINIMAL SOURCE zip packages in that directory, containing ONLY the source directory contents. Along with a readme which tells that the source zips in that directory can only be used in combination with the binary zips. Source packages which are available via http should contain the full docs. This avoids two problems: - people would otherwise have to download the old exe even if they only wanted the docs, for example for creating derived versions of the sources - programmers would otherwise easily forget to update the docs or, even worse, the NLS files when they modify the source code An alternative solution for all the hassles might be to have the docs in a third zip. Then you would have to download 2 of 3 zips for development and 2 of 3 zips for using the program. And all 3 zips would have minimal size. If anybody cares for size of source packages. Still I would really prefer to have all docs in the source zips! After all, people usually download only the sources of SELECTED packages. And the open source idea tells me that the sources are the origins of the world, so it should not be necessary to download the binary package to understand the sources. Eric -- This email message has been encrypted using the ROT-26 cipher. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Fall is my favorite season in Los Angeles, watching the birds change color and fall from the trees. David Letterman (1947 - ) See ya - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
[Freedos-devel] freedos package spec problem: sources, binary, docs
Hi! 27-???-2006 23:50 [EMAIL PROTECTED] (Eric Auer) wrote to freedos-devel@lists.sourceforge.net: EA Blair pointed me to the fact that source packages EA are not supposed to contain docs, according to our EA specs. I object that recommendation. In my opinion, EA source packages should contain everything outside EA the bin directory, and binary packages should EA contain everything outside the source directory. Let me disagree. Source package should contain only sources and other files, which not need for program' user (not developer). Binary package shouldn't contain these files. For example, doc/emm386/build.txt should be present only in sources package, but it not need in binary package. And vice versa: if someone needs source package, then binary package should be installed together. EA My reason for this recommendation is that end users EA should have all documentation and that all documen- EA tation in fact IS part of the source code. When we Documentation is need for program using and should be included into binary package. Or, you may use triple-architecture: binary package (executables and other (data) files, which need for those executables), documentation package (user guides, help files, etc.), source package (sources and developer manuals/technotes). EA work on updating a program, it has to be sufficient EA to download ONLY the source package to create a new EA version of the full binary package. If it need source package, then it already have (or may download) binary package. PS: CuteMouse is packaged in different way: there is _complete_ package (executables and sources) and there is (reduced) binary package. :) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freedos package spec problem: sources, binary, docs
Hi! Let me disagree. Source package should contain only sources and other files, which not need for program' user (not developer). Binary package shouldn't contain these files. For example, doc/emm386/build.txt should be present only in sources package, but it not need in binary package. And vice versa: if someone needs source package, then binary package should be installed together. Documentation is need for program using and should be included into binary package. For example MEM has no devel docs. It only has user docs, license info, and mem.* NLS files. The latter two are definitely relevant for both the source and the binary: For example the NLS files contain format strings and are closely linked to the sources. And it would surely not hurt if developers would actually read and, more importantly, update, the documentation when they modify the sources. But yes, your CuteMouse packaging is also useful: Including the binary in both the binary and docs and the everything package. After all, people who want the sources do accept to download more than people who only want to use the program. If that more also includes the binary, it makes the download a bit bigger, but not that much. Unless anti-binary antivir- us products complain, your method is quite nice. A BINARY package and a FULL package. As opposed to a BINARY package and a SOURCE package. To bring this in context of our installer: The sources included CDROM could just contain ONE set of FULL packages and selectively skip files in source/ directories at the moment when the packages are unzipped. That would also allow full 8 char file names (no need to add x or s to the package name). The binary only CDROM can contain the classic binary and docs (excluding developer-only docs, as mentioned by Aitor) packages. Oh, and last but not least, actually the binary only CDROM need not contain ANY packages at all. Just install all packages into the LiveCD part, and XCOPY that to harddisk for installing it ;-). You can ZIP the ISO itself then. Which will also give better compression than zipping all packages separately :-). You can see this in context of my preference to have the following 4 ISOs: Base binary, Base with sources and LiveCD, Allpackages binary with LiveCD, Allpackages with sources (and optionally LiveCD). Base binary can be whatever makes the download as small as possible. If that is LiveCD and XCOPY instead of zips, fine for me :-). Eric - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freedos package spec problem: sources, binary, docs
Hi, 2006/8/28, Eric Auer [EMAIL PROTECTED]: To bring this in context of our installer: The sources included CDROM could just contain ONE set of FULL packages and selectively skip files in source/ directories at the moment when the packages are unzipped. That would also allow full 8 char file names (no need to add x or s to the package name). The binary only CDROM can contain the classic binary and docs (excluding developer-only docs, as mentioned by Aitor) packages. How would you distinguish these by name then? Aitor - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freedos package spec problem: sources, binary, docs
Just another one: perhaps we should think and standarize the HELP (HTML-Help) directories, so that we distribute the HTM with the packages itself, as opposed to submit them to the HTML-Help maintainer, and hope that both programs (mine and HTML-Help) will be distributed together with the sync-ed versions. Aitor 2006/8/28, Aitor Santamaría [EMAIL PROTECTED]: Two small notes: (1) The HELP file (for FASTHELP) is probably NOT required in the source package either (2) There are docs that are very specific to sources (e.g. how to build and such), that I myself usually don't pack under DOC, but under SRC\DOC, so that they are only installed with sources (I don't know if I'm doing it well). Aitor PS: Jim, I don't know if you read my message from private mail: I was just trying to ask you if you could allow or invite me to write to you private messages from this account of mine (gmail). I say this as I know your university seemed to have an ellaborate way of granting access to you ;-) 2006/8/28, Jim Hall [EMAIL PROTECTED]: I think you are referring to this mini-HOWTO: http://fd-doc.sourceforge.net/wiki/index.php?n=FdDocEn.Distribution Yes, I agree that the source package should contain everything short of the generated binaries. If there are dupe files, let them be overwritten. This mini-HOWTO needs to be updated to say that. -jh Eric Auer wrote: Hi all, Blair pointed me to the fact that source packages are not supposed to contain docs, according to our specs. I object that recommendation. In my opinion, source packages should contain everything outside the bin directory, and binary packages should contain everything outside the source directory. My reason for this recommendation is that end users should have all documentation and that all documen- tation in fact IS part of the source code. When we work on updating a program, it has to be sufficient to download ONLY the source package to create a new version of the full binary package. One might say that this wastes space in situations where you put both source and binary package zips in one directory. Well. Shit happens. Or if that is not acceptable, one could put MINIMAL SOURCE zip packages in that directory, containing ONLY the source directory contents. Along with a readme which tells that the source zips in that directory can only be used in combination with the binary zips. Source packages which are available via http should contain the full docs. This avoids two problems: - people would otherwise have to download the old exe even if they only wanted the docs, for example for creating derived versions of the sources - programmers would otherwise easily forget to update the docs or, even worse, the NLS files when they modify the source code An alternative solution for all the hassles might be to have the docs in a third zip. Then you would have to download 2 of 3 zips for development and 2 of 3 zips for using the program. And all 3 zips would have minimal size. If anybody cares for size of source packages. Still I would really prefer to have all docs in the source zips! After all, people usually download only the sources of SELECTED packages. And the open source idea tells me that the sources are the origins of the world, so it should not be necessary to download the binary package to understand the sources. Eric -- This email message has been encrypted using the ROT-26 cipher. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freedos package spec problem: sources, binary, docs
I very much like the current spec and would wish to stick to it. I'm not going to go about changing the packaging scheme (especially for the distros). On 8/27/06, Lyrical Nanoha [EMAIL PROTECTED] wrote: On Mon, 28 Aug 2006, Arkady V.Belousov wrote: Documentation is need for program using and should be included into binary package. Or, you may use triple-architecture: binary package (executables and other (data) files, which need for those executables), documentation package (user guides, help files, etc.), source package (sources and developer manuals/technotes). I would *personally* go with the three if feasible since it would be easier that way to make an extremely pared-down installation (such as my one-disk installations) by excluding all documentation - on the other hand it's not all that hard to exclude later if need be. -uso. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Fall is my favorite season in Los Angeles, watching the birds change color and fall from the trees. David Letterman (1947 - ) See ya - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
