Java packages, guidelines, ...

[Nicolas Mailhot]

Le mercredi 26 mars 2008 à 21:36 +0200, Ville Skyttä a écrit :
> On Wednesday 19 March 2008, Nicolas Mailhot wrote:
> > Le mercredi 19 mars 2008 à 23:35 +0200, Ville Skyttä a écrit :
> > > On Tuesday 18 March 2008, Nicolas Mailhot wrote:
> > > >
> > > > This is documented in the jpackage-utils package we've been shipping
> > > > for years, and this documentation is already referenced in the
> > > > "incomplete" java guidelines.
> > >
> > > Could you cite the part of the documentation that provides rationale for
> > > this?
> >
> > The rationale is sort of implicit in the documentation that's true.
> >
> > > I have never grokked it, the docs just say "you shall do this" but don't
> > > give a reason at least in the form I would understand.
> >
> > The reason is just that jpackage-utils is just a pile of dumb scripts
> > doing sed-s on find-s in a few directories, and build-classpath jaf
> > works because there is a jaf.jar symlink on the filesystem.
> >
> > >   IMNSHO the versioning
> > > should be dropped and only the unversioned jars installed.
> >
> > Feel free to add smarts to the scripts.
> 
> Maybe I'm thick, but I still don't understand the need for the versioned ones 
> or exactly what smarts you're talking about.

As, so you want to get rid of the versioned jar not the unversioned
one :p It could work, I don't think we've ever had a hard dep on
versionned jars (they're mainly there because everyone was sick of
finding jars with no obvious version in upstream zips, and to make the
"copy the system jars to some private space" use-case safer)

However removing the version would make the collision danger (the fact
this thread is about) worse, not simpler, and I personally think
explicit filename-level component versions are a better engineering
practice.

> find_jar in java-functions falls back to unversioned jar if it can't find the 
> requested versioned jar [0], so not even things that do "find-jar foo-1.2.3" 
> would break if foo-1.2.3.jar would not be there but foo.jar would.
> 
> Because installing multiple packages that own the same versionless symlink 
> pointing to different files would result in a conflict, we can't really do it 
> anyway.

I've always assumed that in that case the packager/distro would drop the
symlink from the compat package. I didn't write it down because this
case never happened and no one felt in necessary to discuss it, which is
perhaps a strong indication the collision issue does not happen in the
real world (also I'm no more found of writing formal documentation than
your average developer is, so what was not needed immediately was not
written down).

Anyway if you'd have told me when I wrote the jpp 1.5 guidelines they
would serve such a long time without being modified I'd have been very
surprised. They were a pragmatic document intended to help fix
the packaging problems we had then, and as far as I'm concerned anyone
finding problems with them has always been free to propose
changes/complete them as long as he could achieve consensus @jpp. (and I
expected JSR 277 to happen years ago)

The pain of documenting other rules, writing the associated tools, and
convincing everyone owning a package based on the current rules
changing them is worth the rebuild pain seems to have contributed to
powerful inertia. 

> And if a package requires a specific version of some other, it'd 
> need to have a versioned dependency in place in all cases - using the version 
> in find-jar and friends' arguments does not seem to add any value to me.  
> Actually on the contrary: it just adds one more thing that can break.

I have no strong opinion one way or another. I thought it would be
useful to support the case when both foo-1.5 and foo-1.4 were on system,
and to fallback gracefully when foo-1.5 was specified but someone
replaced it with 1.6, but we've never reached the number of packages
that would make the need for such features obvious. OTOH the scripts are
widely distributed so I can't vouch someone is not using them exactly
like this somewhere, and no one ever made a strong case to remove them.

Without the automated build farms we have nowadays, anything requiring a
large package pool rebuild was terribly expensive in manual labor (that
jpp was always short on), so my document tried to allow version swaps,
parallel installs, etc. Unlike other languages Java packages do not
systematically explode on version bumps, (needed in the Enterprise
market where version control is often inexistent). So I didn't design
strong version checks.

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080326/d79b2de2/attachment.sig>