On Tuesday, March 08, 2011 11:38:21 am Anne nicolas wrote: > 2011/3/8 Per Øyvind Karlsen <[email protected]>: > > 2011/3/3 Buchan Milne <[email protected]>: > >> ----- "devzero2000" <[email protected]> wrote: > >>> Apart from the rest - of which i will ask for sponsorship when it > >>> will > >>> be - I wanted to know if there are plans to move to rpm5 by Mageia, > >>> such as Mandriva has been doing lately. > >>> > >>> > >>> Rpm5 already has a builtbot > >>> with Magela and rpm5. I can, if you can think useful or have plan for > >>> this, lay the necessary modification to enter into rpm5 Mageia, with > >>> the features of Mandriva cooker - fingerprint, syslog, etc. without > >>> trademark ecc- and produce a first rpm rpm5 for mageia , which also > >>> contains the functionality required by the passage to the "RPM > >>> ACID " feauture (berkeley db conversion) > >> > >> But, can you: > >> -ensure that all valid packages that build under rpm-4.x (e.g. in > >> Mandriva 2010.x) will build under rpm5? -ensure that all valid packages > >> that install under rpm-4.x will install under rpm-4.x? > > > > No and no (I'm assuming you mean "install under rpm5 will install > > under rpm-4.x"). > > Such guarantees has never been provided with any other rpm versions > > either and would effectively prevent the possibility of doing any > > serious development > > and improvement on rpm itself and packaging. > > > > There's a reason for having backports and why we don't even try aiming > > at such goals either. > > > > If able to give any such guarantees with rpm.org on Mageia you gotta be > > either stupid, insane or a damn liar! ;p > > > > The guarantees and priorities is as always: > > * legacy compatibility for older packages > > (opposed to future compatibility gets kinda hard with the the whole > > time travelling issue and limitations attached to it making future > > hard to reliably > > define;) > > * backportability of current packages > > packages needs to be adapted to follow current policies, practice, > > functionality etc. in the current distribution, while efforts in > > ensuring > > possibility of backports > > needs to be invested in the packaging and adopting along the way rather > > than keep adapting rpm to stay compatible with the packaging which gets > > rather backwards. > > > > Very few changes results in breakage for backports, and where it happens > > it's easy enough to add conditional behaviour, nothing new forcing any > > real changes in long-established practices here.. > > Much of the same breakages and issues you hit, you'll hit just as well in > > newer versions from rpm.org as well.. > > > >> There is no document specifying what has changed, or even when > >> highlighting changes, no-one (@rpm5.org, or @mandriva.com) has bothered > >> to list them so that contributors can save time instead of > >> troubleshooting breakage. > >> > >> Some issues that have impacted me so far: > >> -changed behaviour of %exclude > > > > Ambiguity on %exclude usage is a clear bug, %exclude which is solely > > intended for > > excluding files from a specific package (rather than from being packaged > > at all. removing files at end of %install already fit this purpose > > sufficiently, which should > > make it obvious to most people with understanding of doing technical > > designs in general that wiring already existing functionality into an > > existing function with > > different functionality wouldn't make sense. Also this bug was fixed > > since in later > > releases such as 4.4.6 & 4.4.8 shipped before the rpm.org change, and > > should rather be treated as a regression.) predates the unpackaged files > > check and should *not* be used for other purposes. > > Fixing this is in packaging is *very* trivial and fully backwards > > compatible, not > > fixing this OTOH breaks compatibility. > > > >> -new reserved macros (%sql) > > > > all new macros introduced has the potential of conflicting with others > > and should > > always be fixed, it being reserved is more a benefit IMO as it prevents > > such incidents to go unnoticed (using very generic naming for macros is > > a bad practice in general anyways).. > > fixing this does not break any compatibility either ;) > > > >> -possible race condition between %__os_install_post and processing of > >> %files (.lzma man pages reported missing where they are in fact .xz) > > > > your own packaging mistake independent of rpm version, explained on > > cooker and fixed for you already ;) > > > >> (and of course, the unavailability of the build system - during one of > >> the periods I had the most time to work on packages - due to the rpm5 > >> "upgrade") > >> > >> rpm5 has wasted more than half of the time I could afford to contribute > >> to Mandriva. It seems Mandriva has resources to waste, I don't think we > >> have. > > > > you gotta put short-term and long-term effects up against eachother. > > breakages were already expected long before starting the upgrade, and > > the > > majority of these > > were actually rather in various tools etc. related to rpm rather than > > in rpm itself. > > The existing situation made it hard to maintain and do development of > > rpm in distribution, > > packaging and on a the various tools due to being left with since-long > > unmaintained > > tools used (ie. the older version of the perl bindings that only mandriva > > uses and that has been rewritten from scratch since and actively > > maintained upstream as well) and having to keep work around it and > > moving further and further away from "standard" rpm packaging by keep > > introducing any new functionality, scripts, macros etc. as distro > > specific and harder to collaborate with others on.. > > > > You gotta break a few eggs.. > > Issues hit in Mandriva gets fixed along the way in both cooker and > > upstream in parallel, making extremely few of them of any big concerns > > for other to worry about later. > > Maintenance and development of various tools, packaging etc. and dealing > > with your existing and future issues experienced is something you'll be > > left to deal with alone though.. > > Considering the *major* amount of time and work invested in r&d > > historically always being on Mandriva's end with almost all developers > > employed to work on it full time. The harsh reality of trying to keep > > this up with only a few of these working on it during their limited > > spare time should be obvious.. You're entitled to the freedom of not > > showing any interest in sharing efforts on any of these things (and for > > yourself to blame;), at least you're made aware of competence, skills, > > interest and resources that's been offered and is still available to > > you. :) > > > >> (At present, I am not sure if I will continue to maintain packages in > >> Mandriva, the ones where I need newer packages on non-Mandriva at work > >> which I currently maintain in Mandriva and then rebuild I will maintain > >> for the present, but ones I don't need for work may languish ...) > > > > (Sorry for slow reponse and late reply..:/) > > Thanks for your inputs. Decision was taken some weeks ago and we will > follow it for now. You may have very good reasons on your side, please > respect ours.
Let Mandriva work out the kinks and we can reconsider it after the release. There is no need to have two distributions work on them -- Thomas
