[Mageia-dev] RPM5 AND MAGEIA
thomas at btspuhler.com
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
More information about the Mageia-dev