[Mageia-dev] RPM5 AND MAGEIA

[Thomas Spuhler]

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