On Fri, Nov 09, 2001 at 05:22:50PM +0100, Max Kellermann wrote:
> On 0, Jeff Turner <[EMAIL PROTECTED]> wrote:
> > How about using the jar manifest to store the jar metadata, as Sun
> > intended? Make the jars their own database. A platform-independent
> > database :)
>
>
> Jeff, your idea sounds nice, and I would really like to see Debian
> define the new Java manifest file standard, but I see several
> problems:
>
> Your idea requires the license of any library to allow us to unjar
> their .JAR file, add something to the manifest file, and jar it
> again.. I don't know if that will be a problem. It's somehow derived
> work, but on the other hand, the library (the code) itself is still
> the same, and I think a manifest file cannot be protected by copyright
> law (I only know the copyright law in Germany).
I agree it's an issue, and will do a bit of searching/asking to verify
that, in particular, Sun jars allow manifest modification.
> If this licensing stuff is really a problem, we can't take advantage
> of your idea, because it makes no sense to distribute some JAR files
> with an "extended" manifest, and others have their meta information in
> separate files.
I don't think we can *rely* on jar manifests being modifiable. My
previous suggestion was that there be some logical metadata in the
manifest, and then further physical metadata in a separate file.
Evidently that won't work. It also wasn't practical. I don't want to
hack 'dpkg' to fetch metadata from jars *and* from the system database.
So how about:
- have (optional) logical metadata in the jar manifest
- have a complete superset of that info in a system database, perhaps
deriving that info from that in the manifest. No 'dpkg' hacking
required.
> > - It delegates maintenance of some metadata to the upstream source.
> > Most importantly, dependencies. See Adam Heath's rant in a separate
> > thread, and think of how this could solve the problem.. ;)
>
>
> It's dangerous to delegate critical stuff like dependencies to
> upstream.
Logical, abstract dependencies ("we require xerces 1.4.3"), not physical
dependencies ("we require package libxerces-1.4.3-2").
> Only we know what package should get which name, e.g. xalan for Xalan
> 1.x and xalan2 for Xalan 2.0 and 2.1. The library authors would have
> to know our policy and accept it - you can't demand that.
Right, which is why I'm keen to make this logical/physical metadata
distinction. I guess there would be a "physical" equivalent for every
"logical" item of metadata. Eg for Xalan:
NAME LOGICAL PHYSICAL
---- ------- --------
Package: xalan libxalan-java
Version: 1.2.2 1.2.2-2
Depends: xerces 1.0 libxerces-java
bsf 1.0 libbsf-java
Description: Java version of Xalan.. Java version of Xalan..
So upstream maintains "logical", and Debian packagers maintain
"physical". Going from logical to physical is a "value add" process.
So that's a lot of almost-duplicated fields. It's extra work to either
get upstream to add the logical data to their jars, or to add it
ourselves. Why bother?
Because the logical metadata alone is darn useful! It is
system-independent, so I can use a standard Java tool to find out
exactly what a jar is, and what it depends on.
Imagine you're a sysadmin trying to debug a db problem on a remote
non-Debian box. You come across a jar called "classes12.jar". What the
hell is that? What are it's dependencies? If I update "xerces.jar", will
I break it? Who knows..
Another common scenario. I'm writing a webapp for deployment on Tomcat
3.2.3. I find there's a file "log4j.jar" in $TOMCAT_HOME/lib. My webapp
also uses log4j.jar. So I have a potential conflict, that I cannot
resolve without at least knowing what version is in the log4j.jar.
Endless little situations like this, that I encounter frequently, and
which extra jar metadata would solve.
So if the logical and physical metadata are related but distinct (in
particular, "owned" by different people), how does this involve Debian?
Not much initially. It's establishing a substratum of useful
system-independent metadata, on which a subset of package management
functionality could be layered. Debian is *good* at package management.
What better forum for defining a system-independent subset?
Anyway, I'll go and prototype something, and find out about the
licensing issues. Thanks for the feedback!
--Jeff
>
> Regards,
> Max
