Bug 89744

Summary:	_javadocdir location change ?
Product:	[Retired] Red Hat Linux	Reporter:	Nicolas Mailhot <nicolas.mailhot>
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED NEXTRELEASE	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9	CC:	scop
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-01 08:50:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nicolas Mailhot 2003-04-27 13:24:24 UTC

There's been a lot of arguments on JPackage (http://www.jpackage.org/) list for
moving _javadocdir to a subdir of /usr/share/doc.

Since we share this macro definition with RedHat we'd like to know what your
opinion would be on this change.

Latest Jpackage rpm macros are available in the jpackage-utils macros that can
be downloaded at 

ftp://us.dl.sf.net/pub/sourceforge/jpackage/direct_download/1.5/generic/free/RPMS

some stuff is very raw, other is quite mature, comments are welcome.

Comment 1 Jeff Johnson 2003-04-29 15:33:16 UTC

The location for _javadocdir is configurable, easy enough
to change, very hard to guess what the default value should
be.

So what is JPackage.org using for package dependencies? I've
been looking for Guinea pigs to drill a complete and reliable
set of java specific dependencies, but I know next to nothing
about Java.

Any Java hackers out there?

Comment 2 Nicolas Mailhot 2003-04-29 15:49:06 UTC

Basically everyone agrees javadocs should share a single root since that makes
http exports easier. There's been a lot of arguments lately javadoc is pure
documentation and should move in a subdirectory of the general docdir.

If this is ok with you what def should we use ?

>So what is JPackage.org using for package dependencies?

We are very coarse grained in some aspects and very fine grained in others.
Usually dependency=jar name, with jar name build using aliases when several
implementations exist (we often need several implementations - we are vendor
agnostic, usually there are several free implementation and a single complete
non-free one. Most apps use the common alternative, apps that absoluteny need
the non free part depend on the proprietary implementation directly)

Anyway the easiest way to look at what we are doing is :
- look up the rpm/srpm repository at
ftp://us.dl.sf.net/pub/sourceforge/jpackage/direct_download/1.5/
- ask questions at JPackage-discuss
(http://lists.zarb.org/mailman/listinfo/jpackage-discuss)

Everyone will be very happy to answer/help, we are trying to make life easier
for all rpm users (mainly RH/Mdk one) and a way to do it is work closely with
distributions when possible.

Comment 3 Nicolas Mailhot 2003-05-05 09:44:18 UTC

Was I clear enough or do your need more info ? I fear I was a bit laconic here:)

Comment 4 Nicolas Mailhot 2004-09-01 08:50:45 UTC

I guess this kind of problem can be treated outside of bugzilla now
that RedHat is involved into JPackage