FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 03-25-2008, 07:36 PM
Andrew Overholt
 
Default Java packaging guidelines draft

Hi,

A whole bunch of people helped write the Java packaging guidelines draft
currently on the wiki:

http://fedoraproject.org/wiki/PackagingDrafts/Java

All of the questions and comments and TODOs that were on the page have
been taken care of. I'm sure there are going to be questions and
complaints, but we now feel it's in a state worthy of first draft
presentation.

I've added it to the agenda for the next FPC meeting, but discussion
before then may help get issues dealt with.

Note that we've moved the section on Java webapps to a separate page as
we (myself and Tom Fitzsimmons) feel it is too involved of a section to
include in the Java guidelines themselves. Some also feel it should be
considered in light of general guidelines for web applications. It's
been moved here:

http://fedoraproject.org/wiki/PackagingDrafts/JavaWebApps

Thanks go to Tom Fitzsimmons, Matt Wringe, David Walluck, Permaine
Cheung, Deepak Bhole, Lillian Angel, Nicolas Mailhot, Ville Skyttń,
Jason Tibbets, Lubomir Kundrak, Hans de Goede, Colin Walters, Fernando
Nasser, Gary Benson, Andrew Haley, and others who I'm forgetting.

Andrew

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-25-2008, 08:06 PM
"Tom "spot" Callaway"
 
Default Java packaging guidelines draft

On Tue, 2008-03-25 at 16:36 -0400, Andrew Overholt wrote:
> Hi,
>
> A whole bunch of people helped write the Java packaging guidelines draft
> currently on the wiki:
>
> http://fedoraproject.org/wiki/PackagingDrafts/Java
>
> All of the questions and comments and TODOs that were on the page have
> been taken care of. I'm sure there are going to be questions and
> complaints, but we now feel it's in a state worthy of first draft
> presentation.

Thanks to everyone who did work on this. And now, for my comments:

1. The JPackageNaming exception needs to die. It was a painful
compromise originally, and now, it just needs to be removed. I will vote
-1 on any draft that contains it, unless someone comes up with a much
more convincing rationale for its continued existence.

2. "The JPackage Project has defined standard file system locations and
conventions for use in Java packages. Many distributions have inherited
these conventions and in the vast majority of cases, Fedora follows them
verbatim. We include relevant sections of the JPackage guidelines here
but caution that the canonical document will always reside upstream:
JPackage Guidelines "

I'm not sure what this section is intended to provide. It seems to imply
that the JPackage Guidelines are the real guidelines, in which case,
what point do the Fedora Guidelines serve? I have no problem giving the
JPackage team credit for the origination of many of the Fedora
Guidelines, but to refer to that as "the canonical document" is wrong.
This is supposed to be the canonical document for Fedora Java
Guidelines.

I'd prefer to see this entire section replaced with:

The Fedora Java Guidelines are based on guidelines originally drafted by
the JPackage Project.

3. "If the number of provided JAR files exceeds two, place them into a
sub-directory." What makes two the magic number here? Why not simply
more than 1?

4. "Java packages in Fedora should enumerate their dependencies with
Requires." I think this might need to be a "must", not just a "should".

5. I would like to see a section reminding people that all Java packages
MUST be built from source code, and that pre-built binary files (JARs or
otherwise) are not acceptable. The "Pre-built JAR files / Other bundled
software" is probably intended to do this, but it uses a lot of
"shoulds", and never explicitly states that this must not happen.

6. Please add an example of how to resolve class-path-in-manifest
issues.

7. Go through the entire document and make sure that you're using "must"
and "should" appropriately. "Should" means that you are not required to
do it, its just a good idea. "Must" means that you are required to do
it, and that it will fail a package on review. For example, the "Javadoc
scriptlets" seems like it is a "must" not a "should".

8. "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.

9. I think you've got an accidental line wrap in the example for
"Packaging JAR files that use JNI"

10. It might also be worthwhile to do an "ant" spec template and a
"maven" spec template. I'm not sure how different these two packaging
types would be, but the guidelines seem to imply significant
differences.

~spot

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-25-2008, 08:13 PM
Hans de Goede
 
Default Java packaging guidelines draft

Tom "spot" Callaway wrote:

On Tue, 2008-03-25 at 16:36 -0400, Andrew Overholt wrote:

Hi,

A whole bunch of people helped write the Java packaging guidelines draft
currently on the wiki:

http://fedoraproject.org/wiki/PackagingDrafts/Java

All of the questions and comments and TODOs that were on the page have
been taken care of. I'm sure there are going to be questions and
complaints, but we now feel it's in a state worthy of first draft
presentation.


Thanks to everyone who did work on this. And now, for my comments:



Yes, many thanks to all involved!


1. The JPackageNaming exception needs to die. It was a painful
compromise originally, and now, it just needs to be removed. I will vote
-1 on any draft that contains it, unless someone comes up with a much
more convincing rationale for its continued existence.



? Can someone explain to me what is meant with JPackageNaming?


2. "The JPackage Project has defined standard file system locations and
conventions for use in Java packages. Many distributions have inherited
these conventions and in the vast majority of cases, Fedora follows them
verbatim. We include relevant sections of the JPackage guidelines here
but caution that the canonical document will always reside upstream:
JPackage Guidelines "

I'm not sure what this section is intended to provide. It seems to imply
that the JPackage Guidelines are the real guidelines, in which case,
what point do the Fedora Guidelines serve? I have no problem giving the
JPackage team credit for the origination of many of the Fedora
Guidelines, but to refer to that as "the canonical document" is wrong.
This is supposed to be the canonical document for Fedora Java
Guidelines.

I'd prefer to see this entire section replaced with:

The Fedora Java Guidelines are based on guidelines originally drafted by
the JPackage Project.



+1


3. "If the number of provided JAR files exceeds two, place them into a
sub-directory." What makes two the magic number here? Why not simply
more than 1?



+1


4. "Java packages in Fedora should enumerate their dependencies with
Requires." I think this might need to be a "must", not just a "should".



+1, any needed jars (or rather there containing packages) which are not part of
the jre should be required.


5. I would like to see a section reminding people that all Java packages
MUST be built from source code, and that pre-built binary files (JARs or
otherwise) are not acceptable. The "Pre-built JAR files / Other bundled
software" is probably intended to do this, but it uses a lot of
"shoulds", and never explicitly states that this must not happen.



+1


6. Please add an example of how to resolve class-path-in-manifest
issues.



+1


7. Go through the entire document and make sure that you're using "must"
and "should" appropriately. "Should" means that you are not required to
do it, its just a good idea. "Must" means that you are required to do
it, and that it will fail a package on review. For example, the "Javadoc
scriptlets" seems like it is a "must" not a "should".



+1


8. "%{_jnidir} usually expands into /usr/lib/java." This should probably
be %{_libdir}/java.



Yes it should are rather must be %{_libdir}/java

Regards,

Hans

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-25-2008, 08:19 PM
"Tom "spot" Callaway"
 
Default Java packaging guidelines draft

On Tue, 2008-03-25 at 22:13 +0100, Hans de Goede wrote:
> ? Can someone explain to me what is meant with JPackageNaming?

All of the packages which originated from the JPackage repository had a
"repotag" of jpp on them. When they were merged into Fedora Core
(pre-Core/Extras merge), they kept their jpp repotag. When the merger
happened, we tried to get rid of the repotag, because it was a violation
of the NamingGuidelines, but we got a huge amount of pushback on this.

Finally, simply to get past the issue, we drafted a temporary
compromise, letting the repotag remain until it was no longer useful.
The intent was to provide some time for the Java packagers to work out
alternate methods to perform the tasks that they were reliant upon the
repotag for... but no such work ever took place.

In fact, upon retrospection, I'm not entirely sure what value the
repotag holds, which is why it either needs to be thoroughly
rationalized, or gotten rid of entirely.

~spot

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-25-2008, 08:49 PM
Axel Thimm
 
Default Java packaging guidelines draft

On Tue, Mar 25, 2008 at 05:19:24PM -0400, Tom spot Callaway wrote:
> On Tue, 2008-03-25 at 22:13 +0100, Hans de Goede wrote:
> > ? Can someone explain to me what is meant with JPackageNaming?
>
> All of the packages which originated from the JPackage repository had a
> "repotag" of jpp on them. When they were merged into Fedora Core
> (pre-Core/Extras merge), they kept their jpp repotag. When the merger
> happened, we tried to get rid of the repotag, because it was a violation
> of the NamingGuidelines, but we got a huge amount of pushback on this.
>
> Finally, simply to get past the issue, we drafted a temporary
> compromise, letting the repotag remain until it was no longer useful.
> The intent was to provide some time for the Java packagers to work out
> alternate methods to perform the tasks that they were reliant upon the
> repotag for... but no such work ever took place.
>
> In fact, upon retrospection, I'm not entirely sure what value the
> repotag holds, which is why it either needs to be thoroughly
> rationalized, or gotten rid of entirely.

The idea was to treat jpackage as an upstream vendor such that Fedora
imports jpackage rpms, does some modifications on them, but still the
next jpackage release would win over the "local" Fedora modifications.

The same argument that undoes jpackage's guidelines as canonical over
Fedora's applied here would mean that this setup is no longer wanted
anymore.

W/o being involved in jpackage I kinda liked their cross-distribution
type of work. Perhaps the Fedora java guidelines could flow back into
jpackage's. After all there are many jpackage folks around here.
--
Axel.Thimm at ATrpms.net
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-25-2008, 09:03 PM
Nicolas Mailhot
 
Default Java packaging guidelines draft

Le mardi 25 mars 2008 ├* 17:06 -0400, Tom "spot" Callaway a ├ęcrit :
> On Tue, 2008-03-25 at 16:36 -0400, Andrew Overholt wrote:
> > Hi,
> >
> > A whole bunch of people helped write the Java packaging guidelines draft
> > currently on the wiki:
> >
> > http://fedoraproject.org/wiki/PackagingDrafts/Java
> >
> > All of the questions and comments and TODOs that were on the page have
> > been taken care of. I'm sure there are going to be questions and
> > complaints, but we now feel it's in a state worthy of first draft
> > presentation.
>
> Thanks to everyone who did work on this. And now, for my comments:
>
> 1. The JPackageNaming exception needs to die. It was a painful
> compromise originally, and now, it just needs to be removed. I will vote
> -1 on any draft that contains it, unless someone comes up with a much
> more convincing rationale for its continued existence.

I don't see what changed since the discussion on ´╗┐JPackageNaming. The
original arguments still stand, and no further element occurred to my
knowledge to justify changing the compromise that was painfully
achieved.

> 2. "The JPackage Project has defined standard file system locations and
> conventions for use in Java packages. Many distributions have inherited
> these conventions and in the vast majority of cases, Fedora follows them
> verbatim. We include relevant sections of the JPackage guidelines here
> but caution that the canonical document will always reside upstream:
> JPackage Guidelines "
>
> I'm not sure what this section is intended to provide. It seems to imply
> that the JPackage Guidelines are the real guidelines, in which case,
> what point do the Fedora Guidelines serve? I have no problem giving the
> JPackage team credit for the origination of many of the Fedora
> Guidelines, but to refer to that as "the canonical document" is wrong.
> This is supposed to be the canonical document for Fedora Java
> Guidelines.

It's canonical in the sense it's an external document we respect, just
like the FHS, the freedesktop.org specs, etc are external conventions we
respect. Must each of those documents be parroted in our guidelines to
indicate we follow them?

> I'd prefer to see this entire section replaced with:
>
> The Fedora Java Guidelines are based on guidelines originally drafted by
> the JPackage Project.

Fedora has a voice in having the JPP guidelines changes BTW should it be
necessary. You don't need to pull them in Fedora to get some control.

> 3. "If the number of provided JAR files exceeds two, place them into a
> sub-directory." What makes two the magic number here? Why not simply
> more than 1?

When the JPP guidelines were written, a magic number was needed, and 2
was a reasonable choice given the composition of the jpp repo at the
time (ie there were several heavily used packages with just 2 jars, and
the pain of changing them was not worth it). It does not mean anything
more than that.

> 8. "%{_jnidir} usually expands into /usr/lib/java." This should probably
> be %{_libdir}/java.

The original jpp tools scripts are not multilib-safe (I didn't have a
x86_64 system available when I wrote them). When the problem was
identified by people with the right hardware, a quickfix (proposed by RH
IIRC) consisted in changing all the ´╗┐%{_libdir}s in the original
guidelines with ´╗┐/usr/lib.

Since then no one took the time to make the scripts multilib-safe.

> 10. It might also be worthwhile to do an "ant" spec template and a
> "maven" spec template. I'm not sure how different these two packaging
> types would be, but the guidelines seem to imply significant
> differences.

I fear the ant case is likely to be quite un-representative. It would be
like making a "make" case without the GNU project having imposed strong
conventions on standard makefile targets.

--
Nicolas Mailhot
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-25-2008, 09:24 PM
Jason L Tibbitts III
 
Default Java packaging guidelines draft

>>>>> "NM" == Nicolas Mailhot <nicolas.mailhot@laposte.net> writes:

NM> I don't see what changed since the discussion on
NM> ´╗┐JPackageNaming

Actually a whole pile of stuff has changed then.

One of the action items from the conference call I attended recently
was that Fernando would actually document the reasons why we needed
(and, perhaps, still need) the jpp tag. If for no other reason than
we'll actually know. One reason that I recall heading during the
conference was the need to be able to easily query for all of the java
packages on the system in some manner, and we have better query tools
now (along with packagekit to abstract this kind of thing). Perhaps
someone else who was on that call (Jesse?) can say whether I'm
misremembering.

But it's certainly a reasonable time to revisit the issue, although
it's going to be tough to discuss much without that documentation
about the reasons for the tag.

- J<

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-26-2008, 12:07 AM
Jesse Keating
 
Default Java packaging guidelines draft

On Tue, 2008-03-25 at 23:49 +0200, Axel Thimm wrote:
>
> W/o being involved in jpackage I kinda liked their cross-distribution
> type of work. Perhaps the Fedora java guidelines could flow back into
> jpackage's. After all there are many jpackage folks around here.

The conference call I was on with jpackage and RH and Fedora folks last
week seemed to assume that the Fedora Packaging Guidelines would
service /as/ the Jpackage guidelines, period.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-26-2008, 12:09 AM
Jesse Keating
 
Default Java packaging guidelines draft

On Tue, 2008-03-25 at 23:03 +0100, Nicolas Mailhot wrote:
> I don't see what changed since the discussion on ´╗┐JPackageNaming. The
> original arguments still stand, and no further element occurred to my
> knowledge to justify changing the compromise that was painfully
> achieved.

These reasons need to be actually enumerated somewhere, so that they can
be re-examined with today's tools, and if today's tools aren't up to the
task we can have a target to shoot for with tomorrow's tools. Thus far
I have only seen hand wavy reasons as to why it's "needed" and no clear
statements as to what problems are being solved with their existence.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 03-26-2008, 12:09 AM
Jesse Keating
 
Default Java packaging guidelines draft

On Tue, 2008-03-25 at 17:24 -0500, Jason L Tibbitts III wrote:
> Actually a whole pile of stuff has changed then.
>
> One of the action items from the conference call I attended recently
> was that Fernando would actually document the reasons why we needed
> (and, perhaps, still need) the jpp tag. If for no other reason than
> we'll actually know. One reason that I recall heading during the
> conference was the need to be able to easily query for all of the java
> packages on the system in some manner, and we have better query tools
> now (along with packagekit to abstract this kind of thing). Perhaps
> someone else who was on that call (Jesse?) can say whether I'm
> misremembering.
>
> But it's certainly a reasonable time to revisit the issue, although
> it's going to be tough to discuss much without that documentation
> about the reasons for the tag.

You got it right Jason, thanks!

--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 

Thread Tools




All times are GMT. The time now is 07:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org