[Mageia-dev] RPM5 AND MAGEIA

[Per Øyvind Karlsen]

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..:/)
--
Regards,
Per Øyvind