[Mageia-dev] packages importing: what replaces rpm-mandriva-setup-build

Sun Jan 9 05:04:59 CET 2011

2011/1/9 Anssi Hannula <anssi.hannula at iki.fi>:
+> On 08.01.2011 17:08, Jerome Quelin wrote:
+>> hi,
+>>
+>> perl does:
+>>
+>>     BuildRequires: rpm-mandriva-setup-build >= 1.8
+>>
+>> what should it be translated to? rpm-mageia-setup-build?
+>> or nothing at all, since we'll have the latest & greatest version? :-)
+>
+> I'd say it could be made simply "rpm-setup-build" (i.e. merging both
+Yupp, that would be a more uhm.. canonical/binary package compatible
+approach, but of course, one would have to go through the huge task of
+adding the provides for it to the package. ;)
+> "rpm-mandriva-setup" and "rpm-manbo-setup" to "rpm-setup"),
+Yes, the need for a separate rpm-manbo-setup package isn't really
+there anymore..
+> but I guess that really depends on how the rpm*setup maintainer/importer
+> handles it :)
+I personally haven't really cared too much about making any big
+changes to these packages, a lot of their content is either derived
+from rpm5 upstream or made their way into rpm5 upstream from them.
+making a lot of it redundant (ie. I plan on start dropping what's
+redundant once rpm 5.3.7 hits main/release in cooker). I plan on
+reviewing all of it and merge/replace what's appropriate in a generic
+way upstream, eventually phasing out these and other packages that
+carries local macros, helper scripts etc. required for building rpm
+packages in the distribution.
+The goal of doing so is to try standardize functionality, practices,
+policies etc. used for building packages upstream and clean up our
+packaging to make it easier and less messy to maintain (ie. one
+example is disttag & distepoch replacing our own %mkrel, and also
+moved out of the individual spec files)..
+
+I don't know much about your plans are for what direction to choose
+for rpm (my bias is rather obvious, but refactorization & maintenance
+is rathed rather high on my priority list, making me tout rpm5;), but
+I don't mind try adapting if going in a different direction or putting
+any decission on hold; if you're interested in sharing maintenance
+efforts rather than forking these things completely and maintain on
+your own, it's not very painful for me to make changes conditional
+rather than dropping what's no longer in use..
+For any new features implemented and adopted, you'll have to
+cherry-pick and port yourself to stay compatible, I'm too comfortable
+with not having to relate to two different APIs and codebases anymore
+now (if interested, I could help assist you on writing something
+equivalent for compatibility wrapping similar to what I did in the
+past with rpm4compat.h & rpm46compat.h to make ie. URPM able to use
+rpm 4.4 & 4.6 api with rpm5, let's say rpm5compat.h or something).
+
+Whatever you end up doing, don't be afraid of asking or trying to
+communicate on, the mutual benefits of collaboration are rather
+obvious. <;o)
+If not, sorry for imposing.
+
+--
+Regards,
+Per Øyviind
+