[Mageia-dev] RPM5 AND MAGEIA

Anne nicolas ennael1 at gmail.com
Tue Mar 8 19:38:21 CET 2011

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.


More information about the Mageia-dev mailing list