Core Packages in Violation of the Fedora Naming Guidelines

Toshio Kuratomi toshio at tiki-lounge.com
Thu Jul 13 01:52:07 UTC 2006


On Wed, 2006-07-12 at 14:14 -0700, Toshio Kuratomi wrote:
> On Wed, 2006-07-12 at 16:58 -0400, Fernando Nasser wrote:
> > Is there any _constructive_ way to resolve this issue?
> > 
> > There is a clear distinction between the Java stack and ordinary 
> > packages, like two levels of upstream, Java-specific develper 
> > communities characteristics, etc.  What about proposing making Gary 
> > Benson's description of the Java packages tagging official for Java 
> > packages, as it has already been used for Fc3 and FC4 
> 
> Could you send a link to Gary Benson's description please?  Then we'll
> be able to comment on the rules the java package naming is following
> currently, rather than just seeing how it deviates from the rest of the
> distribution.

Well, I found these links for emails from Gary Benson.

http://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00082.html
Is a post by gbenson that says that he was going to propose the Xjpp_Nfc
release tag for the Package Naming Guidelines.  Unfortunately, it
doesn't look like he followed up on that at the time.

http://www.redhat.com/archives/fedora-devel-java-list/2005-September/msg00082.html
Is another post by gbenson.  This one says that the local modifications
to the jpackage packages could include bugfixes, native compiled code
and other things that will not get merged with upstream(jpp).  So you do
not want to flip flop from Fedora provided package to jpp package.

http://www.redhat.com/archives/fedora-devel-java-list/2005-September/msg00038.html
Also within that thread is this message from Thomas Fitzsimmons where he
says that Fedora users should prefer Fedora packages when available and
jpackage packages otherwise.  This can't work 100% with either the
Xjpp_Nfc or N.fcZ schemes.  It could with something like 9Xjpp.N.fcZ but
I shudder to think I even mentioned that.

So it looks like the idea of "upgrading" from a Fedora package to
JPackage to Fedora that was expressed by Fernando Nasser [1]_ is an
anti-goal (ie: It is explicitly not the desired behaviour.)

This leaves the use of Xjpp_Nfc to indicate what jpackage version it was
derived from.  Nicolas has said users and packagers need to find this
information in the release tag.  After reading the archives that say
users should stick to Fedora packages when they're available, I don't
see why users should know this.  kernel packages don't have the git tree
they're based off in the filename, only in the changelog for the same
reason.  The package should just work or Fedora will provide an update
that does.

packagers may find it convenient to know the jpackage fork with a glance
at the filename.  But it doesn't need to be there.  It needs to be
readily found by the packager.  Is the filename really the best place
for this?  When you check out the cvs tree for a package, there's no rpm
prebuilt so having the jpp information in the filename doesn't help.
You still have to read the spec file to find out what upstream version
it's built on.  Once you read the spec file, it doesn't matter if its
in the Release, a comment, or a Provides: foo-jpp = 6; they're pretty
much equally convenient.

My first choice, then, would be to not include the jpp version in NEVR.

If someone does come up with a convincing reason to put the jpp version
in the NEVR, then I think the post release snapshot guidelines are the
closest current guidelines.  So jpackage packages would end up like
this:
Current: jgroups-2.2.6-1jpp_4fc.src.rpm
New: jgroups-2.2.6-4.1jpp.fc6.src.rpm
With a cvs snapshot: jgroups-2.2.6-4.1jpp.20060707cvs.fc6.src.rpm

[1]_
http://www.redhat.com/archives/fedora-maintainers/2006-July/msg00255.html

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20060712/b5fb554b/attachment.sig>


More information about the Fedora-maintainers mailing list