2015-06-24 17:11 GMT+02:00 Bernhard Rosenkraenzer <[email protected]>: > On 2015-06-24 16:07, Tomasz Gajc wrote: > > Per what are the real benefits of moving back to rpm.org? >> Does this needs some extra work on perl-URPM, urpmi, mock-urpm and >> various ABF subsystems ? >> > Not really, for perl-URPM, it would mainly be a matter of just replace use of rpm5 API with rpm4 API, which perl-URPM used by mageia uses already.. For this one I'm not likely to just pick up mageia's rpm.org compatible fork and port our changes to, but rather just port to the different API. Considering that being the "biges"t job, while already done by Mageia, just peeking Mageia's should be sufficient and enough toi to pick up...
For compatibility otherwise, I intend to address it in advance to prevent issues from arrising, with work on rpm.org kept out of usage for quite a while all untill ready . :) > > I think there's both benefits (esp. that it's the same thing opensuse and > the likes use, so zypper will automatically get all needed changes) and > drawbacks... > > We rely on stuff that was added in rpm5 in quite a few spec files -- I > haven't looked at rpm.org in a long time, so maybe they have been added > there by now. (Either way they should be fairly easy to add if we decide to > go down that route). What's the status of: > > Filetype triggers > %bcond_with and friends > %apply_patches > Suggests: handling > %track > pkgconfig(*) and cmake(*) dependencies etc. > noarch subpackages in arch specific packages > > in current rpm.org? (And does anyone else remember other rpm5-isms that > may be important for us?) >From the guy who's working pretty much exclusively alone on it, done a poor job of announcing & documenting new features, behaviour & enhancements, there is actually considerably more. Just look at the over 300 locally managed patches in our package repo since November 2011. Then there's work of mine from involvement in rpm5 dating back to ~2008 IIRC, with activity increased quite a bit in 2009, then considerably in increased to full time work on in 2010 & 2011 that's part of upstream before commit access were cut off.. I took a closer (but quite brief look at rpm.org repo, now hosted at github btw.) yesterday (made my first & only commit so far in my repo that felt easier and safiest just to start by applying to begin with; scripts/pythoneggs.py :), much of the stuff that either myself or others implemented and relied on by us seems to have been caught up with in some areas and years later, so a lot won't be needed to be ported, either due to already having the exact same in place now, or some equivalent, which could be worse, for which I'd probably would prefer to implement our replacement/alternative implementation, or in the case of better implemented, making the obvious choice of adapt to the best candidate. :) I have a lot of work related to this projet to catch up with on so many levels, so work on this item on my TODO item isn't ranked the highest, and there is no plans on preparing it for next OMV LX release... ;) -- Regards, Per Øyvind
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
