-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sun, 24 Apr 2005 12:58:48 -0400, Barry Hawkins <[EMAIL PROTECTED]> wrote:
> Petter Reinholdtsen wrote: >> [Barry Hawkins] >> >>>General Recommendations >>>1. Use version numbers almost always. Our current policy[0] shows this >>>as optional, but I believe it should be more the standard we follow by >>>default. Java libraries, in this case Jakarta Commons libraries, are >>>almost always vulnerable to incompatibilities between major versions. >>>Seasoned Ant users and Maven as a whole[1] (thanks Trygve LaugstÃl) have >>>chosen versioned .jar files to address this. >> >> Sounds like you are proposing so-name versioning for Java. Done >> right, it is a good idea. Done wrong it isn't. :) We depend on upstream versionning scheme :( >> The librariy packages should have a version number that changes >> whenever there is an incompatible change in the library binary. No >> more, and no less. That way programs using the library only need to >> rebuild with newer dependencies when needed, and it will keep working >> across library upgrades as long as the library is backward compatbile. > [...] > I didn't particularly have so versioning in mind, but I guess that is a > close analog. I think I follow what you are saying in theory; could you > use the example of Jakarta Commons Collections included in the original > post to explain how your suggestions would either agree with the > proposal or differ from it? If upstream does not respect major version update when the API changes, we have a problem and it's difficult to reflect the change of the API. That's what we (Stefan Gybas and I) did with Struts: libstruts1.1-java and libstruts1.2-java. This is also the case with ant1.5 and ant1.6. I think this issue should be solved by Sun, not by Debian! :-D >>>2. Do not prefix the source package with "lib". Libraries, at least >>>most of the ones worth packaging, almost always ship their docs in >>>the tarballs. Having a source package whose name matches the binary >>>package for the library itself loosely implies that is all it's for. >>>Since some libraries also ship with examples and testing frameworks, >>>this can become even more confusing, as can be seen in the one bug >>>for libcommons-collections3-java[3]. >> >> I do not understand this argument. There are several lib* packages >> with both binaries and documentation included. I do not see that as a >> problem. > [...] > We could certainly have a policy that a given library installs both its > .jars and its documentation; in some ways I think that would simplify > matters. As it stands, the Java libraries look like they are taking a > varied approach. I would think that users who employ these libraries on > production machines would certainly want to be able to exclude the > documentation, so having separate binaries for that The java-policy is maybe not very clear about documentation but it's define in the Debian policy: ,----[ /usr/share/doc/debian-policy/policy.txt.gz ] | 12.3. Additional documentation | ------------------------------ | | Any additional documentation that comes with the package may be | installed at the discretion of the package maintainer. Text | documentation should be installed in the directory | `/usr/share/doc/<package>', where <package> is the name of the | package, and compressed with `gzip -9' unless it is small. | | If a package comes with large amounts of documentation which many | users of the package will not require you should create a separate | binary package to contain it, so that it does not take up disk space | on the machines of users who do not need or want it installed. | [...] `---- So, if the documentation is too big, it should be split in a separate - -doc package, if not, ftp-masters will reject them because these packages are too small. >> As for the java "programs", several of the packages is lacking >> wrappers to start them in /usr/bin/, and I suspect that is the main >> reason people perceive the packages as libraries only. If people >> believe that, that is. I don't believe it. > I am not sure I follow what you are saying here. Are you saying that > certain packages for Java which are applications lack wrapper scripts? > That certainly makes sense. I don't understand the part that you don't > believe. If you could unpack that a bit more, that would be great. I > want to be sure I understand. Thanks for the time investment in > reviewing and replying. There has been bug reports about packages not shipped with wrappers or not all the scripts, fop comes in mind but it's maybe solved. Cheers, - -- .''`. : :' :rnaud `. `' `- Java Trap: http://www.gnu.org/philosophy/java-trap.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCbAKX4vzFZu62tMIRAh3VAJ9U4NKscPqwHz6+bhTd50VdfIdq/QCaAj+e t1qaDYJAPH713TeYrGrdx18= =t2OR -----END PGP SIGNATURE-----
