[Mageia-dev] RPM5 AND MAGEIA

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.
+
+
+-- 
+Anne
+http://www.mageia.org
+