-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. :) > > 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?
>>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 > 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. Thanks, - -- Barry Hawkins All Things Computed site: www.alltc.com weblog: www.yepthatsme.com Registered Linux User #368650 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCa9BHHuKcDICy0QoRAka0AJ9hp3yX5kgPR0wkC2JnnT28QahG7QCeOpsl ydm/mnA6dNSsqqLrbUC3NXs= =V2jp -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
