[Mageia-dev] RPM5 AND MAGEIA

Tue Mar 29 03:18:58 CEST 2011

On Tuesday, March 08, 2011 11:38:21 am Anne nicolas wrote:
+> 2011/3/8 Per Øyvind Karlsen <peroyvind at mandriva.org>:
+> > 2011/3/3 Buchan Milne <bgmilne at staff.telkomsa.net>:
+> >> ----- "devzero2000" <devzero2000 at 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.
+
+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
+