2011/1/9 Anssi Hannula <anssi.hann...@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