Re: Updating Jakarta Commons packages
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sun, 24 Apr 2005 12:58:48 -0400,
Barry Hawkins <barry@bytemason.org> 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-----
Reply to: