diff options
Diffstat (limited to 'zarb-ml/mageia-discuss/20101004/002077.html')
| -rw-r--r-- | zarb-ml/mageia-discuss/20101004/002077.html | 117 |
1 files changed, 117 insertions, 0 deletions
diff --git a/zarb-ml/mageia-discuss/20101004/002077.html b/zarb-ml/mageia-discuss/20101004/002077.html new file mode 100644 index 000000000..3b4eb301f --- /dev/null +++ b/zarb-ml/mageia-discuss/20101004/002077.html @@ -0,0 +1,117 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-discuss] Mageia Mirror size + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Mageia%20Mirror%20size&In-Reply-To=%3Cm3ocbbkjxz.fsf%40euphor.blino.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002081.html"> + <LINK REL="Next" HREF="002079.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-discuss] Mageia Mirror size</H1> + <B>Olivier Blin</B> + <A HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Mageia%20Mirror%20size&In-Reply-To=%3Cm3ocbbkjxz.fsf%40euphor.blino.org%3E" + TITLE="[Mageia-discuss] Mageia Mirror size">mageia at blino.org + </A><BR> + <I>Mon Oct 4 00:09:12 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="002081.html">[Mageia-discuss] Mirror infrastructure setup +</A></li> + <LI>Next message: <A HREF="002079.html">[Mageia-discuss] News about the forum +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2077">[ date ]</a> + <a href="thread.html#2077">[ thread ]</a> + <a href="subject.html#2077">[ subject ]</a> + <a href="author.html#2077">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-discuss">misc at zarb.org</A>> writes: + +>><i> If we have a separate directory for noarch, it could be shared by all +</I>>><i> arches, which means there would be no such unsync issue. +</I>><i> +</I>><i> We have 2 choices : +</I>><i> - all arch synced ( ie, x86 and x86_64 for now, likely arm and others in +</I>><i> the future ) +</I>><i> - main archs synced, others possibly unsynced ( either the time to be +</I>><i> ported, or more "permanently" ). +</I>><i> +</I>><i> In the past, we did it the secund way. Arm was ported from stable +</I>><i> release, ppc, sparc were develop as side arch, etc. +</I>><i> +</I>><i> Since arm buildbots may be slower than x86 builder, using solution 1 +</I>><i> ( everything synced ) can cause trouble. Noarch rpm will be synced, but +</I>><i> since some noarch depend on arch dependent rpms ( like python modules +</I>><i> who depend on the version of python, or packages who produces +</I>><i> arch-dependent and noarch rpms ), we will need to keep also binary rpm +</I>><i> in sync. +</I>><i> So that mean we will have to wait on the slower builder before +</I>><i> uploading. Think of open office, for example. +</I> +Right, we probably don't want to wait for slower arches to finish their +build to push i586/x86_64/src packages on the mirrors. + +Having unsynced noarch packages sort of defeats the goal of noarch +packages, but well, it's probably better than waiting for arm builds on +every upload. +We could use qemu-arm to rebuild ARM packages from x86_64 build hosts +(the OBS way), but rtp would probably not be happy with that, since the +toolchain binaries are not tested on real hardware at build time. + +Using cross-compilantion would be even worse, since the ARM toolchain +binaries would not even be run at build time; so you can get an ARM +toolchain package that is built fine but is never used on the official +build system, meaning you don't know if it can produce correct code, and +you can't really trust it. + +Also, have unsynced ARM tree can cause some deps timing issue at build +time. + +For example, one uploads a new gtk. Just after upload is finished (meaning +built on i586 + x86_64), she uploads a new gimp with a buildrequire on +this new gtk. +This gimp should be built fine on i586 + x86_64, but will not get +through on ARM because the gtk dep will probably not be available yet. + + +Another solution could be the way we handled x86_64 at the beginning of +its port in Mandrake. There was a iurt rebuild bot that was not +triggered at upload time, but running in a loop to rebuild packages +releases that were available on i586 but not yet on x86_64. + +-- +Olivier Blin - blino +</PRE> + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002081.html">[Mageia-discuss] Mirror infrastructure setup +</A></li> + <LI>Next message: <A HREF="002079.html">[Mageia-discuss] News about the forum +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2077">[ date ]</a> + <a href="thread.html#2077">[ thread ]</a> + <a href="subject.html#2077">[ subject ]</a> + <a href="author.html#2077">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-discuss">More information about the Mageia-discuss +mailing list</a><br> +</body></html> |