[Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals

Fernando Nasser fnasser at redhat.com
Fri Jan 12 19:43:23 UTC 2007

Jesse Keating wrote:
> On Friday 12 January 2007 11:48, Fernando Nasser wrote:
>> Yes, we have the changelog entries added for the respin everything
>> cases, some old entries regarding changes that were made for GCJ
>> compilation when it was not as perfect as it is today, some emergency
>> local fixes doen during release times that were incorporated upstream a
>> few days later.  If this is deemed not important we can stopp merging them.
>> We will still add our '.N' release number to the release tag and add a
>> changelog entry saying that we have imported and are rebuilding it with
>> AOT.
>> BTW, so far we had to remove the Vendor and Distribution tags from the
>> upstream spec file too, but that has been removed upstream to make it
>> easier for the distros to import the packages.
> I think adopting a work method that doesn't stomp local changes is very 
> important, including adding an entry about importing from upstream for the 
> build.

Oh yeah, we are very careful to preserve things that have been added for 
one reason or the other.  That is why we don't blindly import the 
upstream releases (it could be even scripted).  It actually becomes an 
opportunity to remove some GCJ hack that is no longer necessary, to 
check if some fix was made locally and not properly incorporated 
upstream (both packaging and in the software code itself) etc.  People 
that have been doing this seem happy, but again I rather not speak for 
them.  Speak up guys!

> I still don't like "jpp" being there, however I suppose I can live with it, 
> provided others on the packaging committee can too, and we create a special 
> case for it (ICK).

That would be the ideal scenario at the moment.  I believe we will have 
other more important cleanups to do as we go through the review process. 
  For instance, it was recently proposed that only files into certain 
directories should be specified as file dependencies.  I don't think it 
become a rule but we can try and restrict to that set if possible. 
Also, check if all spec files use the proper macros to refer to things 
like rm always, see if the new rules for Obsoletes work within this set etc.

That does not mean that we should not be very attentive to the new RPM 
project and try to include things there that would make it unnecessary.
And once those things are available ask for the proper UI changes in Yum 
too.  I don't think this is the only case where we are circumventing 
some missing RPM feature that exists either because nobody thought of it 
or because it is a new need that came to be.


More information about the Fedora-packaging mailing list