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
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
