diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110329/003778.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110329/003778.html | 208 |
1 files changed, 208 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110329/003778.html b/zarb-ml/mageia-dev/20110329/003778.html new file mode 100644 index 000000000..01c5d4eb9 --- /dev/null +++ b/zarb-ml/mageia-dev/20110329/003778.html @@ -0,0 +1,208 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] RPM5 AND MAGEIA + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20RPM5%20AND%20MAGEIA&In-Reply-To=%3C201103281818.58510.thomas%40btspuhler.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + + <LINK REL="Next" HREF="003779.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] RPM5 AND MAGEIA</H1> + <B>Thomas Spuhler</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20RPM5%20AND%20MAGEIA&In-Reply-To=%3C201103281818.58510.thomas%40btspuhler.com%3E" + TITLE="[Mageia-dev] RPM5 AND MAGEIA">thomas at btspuhler.com + </A><BR> + <I>Tue Mar 29 03:18:58 CEST 2011</I> + <P><UL> + + <LI>Next message: <A HREF="003779.html">[Mageia-dev] Switch from scim to ibus +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#3778">[ date ]</a> + <a href="thread.html#3778">[ thread ]</a> + <a href="subject.html#3778">[ subject ]</a> + <a href="author.html#3778">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Tuesday, March 08, 2011 11:38:21 am Anne nicolas wrote: +><i> 2011/3/8 Per Øyvind Karlsen <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">peroyvind at mandriva.org</A>>: +</I>><i> > 2011/3/3 Buchan Milne <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">bgmilne at staff.telkomsa.net</A>>: +</I>><i> >> ----- "devzero2000" <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">devzero2000 at rpm5.org</A>> wrote: +</I>><i> >>> Apart from the rest - of which i will ask for sponsorship when it +</I>><i> >>> will +</I>><i> >>> be - I wanted to know if there are plans to move to rpm5 by Mageia, +</I>><i> >>> such as Mandriva has been doing lately. +</I>><i> >>> +</I>><i> >>> +</I>><i> >>> Rpm5 already has a builtbot +</I>><i> >>> with Magela and rpm5. I can, if you can think useful or have plan for +</I>><i> >>> this, lay the necessary modification to enter into rpm5 Mageia, with +</I>><i> >>> the features of Mandriva cooker - fingerprint, syslog, etc. without +</I>><i> >>> trademark ecc- and produce a first rpm rpm5 for mageia , which also +</I>><i> >>> contains the functionality required by the passage to the "RPM +</I>><i> >>> ACID " feauture (berkeley db conversion) +</I>><i> >> +</I>><i> >> But, can you: +</I>><i> >> -ensure that all valid packages that build under rpm-4.x (e.g. in +</I>><i> >> Mandriva 2010.x) will build under rpm5? -ensure that all valid packages +</I>><i> >> that install under rpm-4.x will install under rpm-4.x? +</I>><i> > +</I>><i> > No and no (I'm assuming you mean "install under rpm5 will install +</I>><i> > under rpm-4.x"). +</I>><i> > Such guarantees has never been provided with any other rpm versions +</I>><i> > either and would effectively prevent the possibility of doing any +</I>><i> > serious development +</I>><i> > and improvement on rpm itself and packaging. +</I>><i> > +</I>><i> > There's a reason for having backports and why we don't even try aiming +</I>><i> > at such goals either. +</I>><i> > +</I>><i> > If able to give any such guarantees with rpm.org on Mageia you gotta be +</I>><i> > either stupid, insane or a damn liar! ;p +</I>><i> > +</I>><i> > The guarantees and priorities is as always: +</I>><i> > * legacy compatibility for older packages +</I>><i> > (opposed to future compatibility gets kinda hard with the the whole +</I>><i> > time travelling issue and limitations attached to it making future +</I>><i> > hard to reliably +</I>><i> > define;) +</I>><i> > * backportability of current packages +</I>><i> > packages needs to be adapted to follow current policies, practice, +</I>><i> > functionality etc. in the current distribution, while efforts in +</I>><i> > ensuring +</I>><i> > possibility of backports +</I>><i> > needs to be invested in the packaging and adopting along the way rather +</I>><i> > than keep adapting rpm to stay compatible with the packaging which gets +</I>><i> > rather backwards. +</I>><i> > +</I>><i> > Very few changes results in breakage for backports, and where it happens +</I>><i> > it's easy enough to add conditional behaviour, nothing new forcing any +</I>><i> > real changes in long-established practices here.. +</I>><i> > Much of the same breakages and issues you hit, you'll hit just as well in +</I>><i> > newer versions from rpm.org as well.. +</I>><i> > +</I>><i> >> There is no document specifying what has changed, or even when +</I>><i> >> highlighting changes, no-one (@rpm5.org, or @mandriva.com) has bothered +</I>><i> >> to list them so that contributors can save time instead of +</I>><i> >> troubleshooting breakage. +</I>><i> >> +</I>><i> >> Some issues that have impacted me so far: +</I>><i> >> -changed behaviour of %exclude +</I>><i> > +</I>><i> > Ambiguity on %exclude usage is a clear bug, %exclude which is solely +</I>><i> > intended for +</I>><i> > excluding files from a specific package (rather than from being packaged +</I>><i> > at all. removing files at end of %install already fit this purpose +</I>><i> > sufficiently, which should +</I>><i> > make it obvious to most people with understanding of doing technical +</I>><i> > designs in general that wiring already existing functionality into an +</I>><i> > existing function with +</I>><i> > different functionality wouldn't make sense. Also this bug was fixed +</I>><i> > since in later +</I>><i> > releases such as 4.4.6 & 4.4.8 shipped before the rpm.org change, and +</I>><i> > should rather be treated as a regression.) predates the unpackaged files +</I>><i> > check and should *not* be used for other purposes. +</I>><i> > Fixing this is in packaging is *very* trivial and fully backwards +</I>><i> > compatible, not +</I>><i> > fixing this OTOH breaks compatibility. +</I>><i> > +</I>><i> >> -new reserved macros (%sql) +</I>><i> > +</I>><i> > all new macros introduced has the potential of conflicting with others +</I>><i> > and should +</I>><i> > always be fixed, it being reserved is more a benefit IMO as it prevents +</I>><i> > such incidents to go unnoticed (using very generic naming for macros is +</I>><i> > a bad practice in general anyways).. +</I>><i> > fixing this does not break any compatibility either ;) +</I>><i> > +</I>><i> >> -possible race condition between %__os_install_post and processing of +</I>><i> >> %files (.lzma man pages reported missing where they are in fact .xz) +</I>><i> > +</I>><i> > your own packaging mistake independent of rpm version, explained on +</I>><i> > cooker and fixed for you already ;) +</I>><i> > +</I>><i> >> (and of course, the unavailability of the build system - during one of +</I>><i> >> the periods I had the most time to work on packages - due to the rpm5 +</I>><i> >> "upgrade") +</I>><i> >> +</I>><i> >> rpm5 has wasted more than half of the time I could afford to contribute +</I>><i> >> to Mandriva. It seems Mandriva has resources to waste, I don't think we +</I>><i> >> have. +</I>><i> > +</I>><i> > you gotta put short-term and long-term effects up against eachother. +</I>><i> > breakages were already expected long before starting the upgrade, and +</I>><i> > the +</I>><i> > majority of these +</I>><i> > were actually rather in various tools etc. related to rpm rather than +</I>><i> > in rpm itself. +</I>><i> > The existing situation made it hard to maintain and do development of +</I>><i> > rpm in distribution, +</I>><i> > packaging and on a the various tools due to being left with since-long +</I>><i> > unmaintained +</I>><i> > tools used (ie. the older version of the perl bindings that only mandriva +</I>><i> > uses and that has been rewritten from scratch since and actively +</I>><i> > maintained upstream as well) and having to keep work around it and +</I>><i> > moving further and further away from "standard" rpm packaging by keep +</I>><i> > introducing any new functionality, scripts, macros etc. as distro +</I>><i> > specific and harder to collaborate with others on.. +</I>><i> > +</I>><i> > You gotta break a few eggs.. +</I>><i> > Issues hit in Mandriva gets fixed along the way in both cooker and +</I>><i> > upstream in parallel, making extremely few of them of any big concerns +</I>><i> > for other to worry about later. +</I>><i> > Maintenance and development of various tools, packaging etc. and dealing +</I>><i> > with your existing and future issues experienced is something you'll be +</I>><i> > left to deal with alone though.. +</I>><i> > Considering the *major* amount of time and work invested in r&d +</I>><i> > historically always being on Mandriva's end with almost all developers +</I>><i> > employed to work on it full time. The harsh reality of trying to keep +</I>><i> > this up with only a few of these working on it during their limited +</I>><i> > spare time should be obvious.. You're entitled to the freedom of not +</I>><i> > showing any interest in sharing efforts on any of these things (and for +</I>><i> > yourself to blame;), at least you're made aware of competence, skills, +</I>><i> > interest and resources that's been offered and is still available to +</I>><i> > you. :) +</I>><i> > +</I>><i> >> (At present, I am not sure if I will continue to maintain packages in +</I>><i> >> Mandriva, the ones where I need newer packages on non-Mandriva at work +</I>><i> >> which I currently maintain in Mandriva and then rebuild I will maintain +</I>><i> >> for the present, but ones I don't need for work may languish ...) +</I>><i> > +</I>><i> > (Sorry for slow reponse and late reply..:/) +</I>><i> +</I>><i> Thanks for your inputs. Decision was taken some weeks ago and we will +</I>><i> follow it for now. You may have very good reasons on your side, please +</I>><i> respect ours. +</I> +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 +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + + <LI>Next message: <A HREF="003779.html">[Mageia-dev] Switch from scim to ibus +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#3778">[ date ]</a> + <a href="thread.html#3778">[ thread ]</a> + <a href="subject.html#3778">[ subject ]</a> + <a href="author.html#3778">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |