9. feb. 2012 18.06 skrev letters.random13 <[email protected]>: > > > On Tue, Feb 7, 2012 at 12:34 AM, Carsten Munk <[email protected]> > wrote: >> >> Apologies for the late reply, I've been on FOSDEM and business trip. >> >> rpmlint-mini originates from opensuse and is meant to be a way to >> avoid dragging in entire python dependancies, which may be >> significantly a fair bit, especially if you're trying to bootstrap the >> base system >> >> rpmlint-mini will install into /opt/testing/bin or something, with >> it's own set of python modules and python itself. >> >> There should be a python RPM macro that determines version, maybe you >> can use this to vary the choice of -deps file? > > > thanks, > [i vote to eliminate -mini, then add back after py2.7 is stable... it seems > unmaintainable (across python version bumps) in a build system] > > haven't found a finesse solution, only brute force. > now looking for source of mystery pkg > > rpmlint-mini-x86-arm-1.1-1.11 > > closest in mer git that i can find is: > mer-crosshelpers/rpmlint-mini-x86.git > but don't know what would lead to -arm. > on 1st scan, all files look the same as rpmlint-mini, except for .wrapper? > could this be ifarched back into that pkg to ease maintenance / duplication? > rpmlint-mini-x86 is also (not so obviously) broken by py2.7 (on cobs at > least?), x86-arm also, i assume. > > tl;dr is latest comment of https://bugs.merproject.org/show_bug.cgi?id=169
Don't bother with rpmlint-mini-x86, it has gotten replaced by an entirely different approach in SB2 integration (new cross compilation), so we use rpmlint-mini from x86 directly, unmodified from there. BR Carsten Munk
