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.
Cheers,
Fernando
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
