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