diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110315/003345.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110315/003345.html | 157 |
1 files changed, 157 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110315/003345.html b/zarb-ml/mageia-dev/20110315/003345.html new file mode 100644 index 000000000..b4fd35058 --- /dev/null +++ b/zarb-ml/mageia-dev/20110315/003345.html @@ -0,0 +1,157 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Packaging errors to fix + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Packaging%20errors%20to%20fix&In-Reply-To=%3C201103152257.59200.maarten.vanraes%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="003339.html"> + <LINK REL="Next" HREF="003328.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Packaging errors to fix</H1> + <B>Maarten Vanraes</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Packaging%20errors%20to%20fix&In-Reply-To=%3C201103152257.59200.maarten.vanraes%40gmail.com%3E" + TITLE="[Mageia-dev] Packaging errors to fix">maarten.vanraes at gmail.com + </A><BR> + <I>Tue Mar 15 22:57:59 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="003339.html">[Mageia-dev] Packaging errors to fix +</A></li> + <LI>Next message: <A HREF="003328.html">[Mageia-dev] Packages cannot be searched in MCC +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#3345">[ date ]</a> + <a href="thread.html#3345">[ thread ]</a> + <a href="subject.html#3345">[ subject ]</a> + <a href="author.html#3345">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op dinsdag 15 maart 2011 19:06:28 schreef Michael Scherer: +><i> Le mardi 15 mars 2011 à 18:34 +0200, Anssi Hannula a écrit : +</I>><i> > On 15.03.2011 15:38, Michael Scherer wrote: +</I>><i> > > 3rd : dbus. There is a vicious loop between dbus and its own library, +</I>><i> > +</I>><i> > So? Both of the requires are correct from what I know, and dependency +</I>><i> > loops are not forbidden. +</I>><i> > +</I>><i> > I can imagine there are also some more clear cases of such loops, like +</I>><i> > library A depending on B, B on C, and C again on A, which I personally +</I>><i> > don't believe are in the need of "solving". +</I>><i> +</I>><i> We did have some troubles with loops at building time when we +</I>><i> bootstrapped the distribution, and we clearly wanted to remove them as +</I>><i> much as possible. +</I>><i> +</I>><i> A loop at runtime is potentially the sign of a loop at build time too. +</I>><i> So we should try to avoid them IMHO. +</I>><i> +</I>><i> In the case of dbus, yes, the requires are correct, but the ordering +</I>><i> seems wrong during the test. So either there is a bug in what ever jbj +</I>><i> is running, or we do use Requires(post) in a wrong way, or that's a +</I>><i> change somewhere. In any case, there is still the others problem to look +</I>><i> at :) +</I> +imho, i think if loops are unneeded or solvable, we should try to do that if +it's doable in a short time. + +when we were talking about loops at bootstrap time, this is a whole different +area, i think most of the loops are not really solvable, but we should find a +way to make it easier and possibly documented, or even automagically... + +for example: + - you can bootstrap X by installing Y without functionality Z + +if we would have some way to note how this is done, perhaps we can even do it +automagically on buildsystem level. + +looking at this from my pov, perhaps having a spec file macro isn't a bad idea: + +%bootstrap(%feature1 %feature2 ...) + +would be nice, if building it with for example --bootstrap, would deactivate +all those features + +then you could let buildsystem build once with --bootstrap and once without it +after the dependencies are done + +if you'd look at things even more, we could do something like this: + +%build_order(<group>:<order_nr>) + +then with buildsystem one could build a bunch of packages and the buildsystem +could order them according to the group. + + +eg java: (totally fictional example, i know nothing about java packaging) +============================================ + +in package A: +---------------- +%bootstrap(maven eclipse) +%build_order(java:1) + +%if %maven +... +%endif + + + +in package B: +---------------- +%bootstrap(maven) +%build_order(java:2) + +%if %maven +... +%endif + + +in package maven: +----------------------- +%bootstrap(eclipse) +%build_order(java:500) + + + +you will all agree that i'm talking bollocks here, as this is totally not how +it is. + +However, if you have something like this, you could theoretically say to +buildsystem: "build java for me" + +it could then find all spec files with build_order java, sort them on the +number, and build and submit them all in the order. and after it's done, do +this again with the ones that had bootstrap defined. + + +to me, it sounds like a good theoretical solution and it would still be +usefull, even after bootstrapping. no idea if it would take alot of work or +not or even practically possible. +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="003339.html">[Mageia-dev] Packaging errors to fix +</A></li> + <LI>Next message: <A HREF="003328.html">[Mageia-dev] Packages cannot be searched in MCC +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#3345">[ date ]</a> + <a href="thread.html#3345">[ thread ]</a> + <a href="subject.html#3345">[ subject ]</a> + <a href="author.html#3345">[ 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> |