[Fedora-packaging] Java (jpackage) naming scheme rehash -- part 1 Goals
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
>> 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
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