2011/3/8 Per Øyvind Karlsen <peroyv...@mandriva.org>: > 2011/3/3 Buchan Milne <bgmi...@staff.telkomsa.net>: >> >> ----- "devzero2000" <devzero2...@rpm5.org> 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. -- Anne http://www.mageia.org