diff options
| author | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
|---|---|---|
| committer | Nicolas Vigier <boklm@mageia.org> | 2013-04-14 13:46:12 +0000 |
| commit | 1be510f9529cb082f802408b472a77d074b394c0 (patch) | |
| tree | b175f9d5fcb107576dabc768e7bd04d4a3e491a0 /zarb-ml/mageia-dev/20101129 | |
| parent | fa5098cf210b23ab4f419913e28af7b1b07dafb2 (diff) | |
| download | archives-master.tar archives-master.tar.gz archives-master.tar.bz2 archives-master.tar.xz archives-master.zip | |
Diffstat (limited to 'zarb-ml/mageia-dev/20101129')
53 files changed, 7481 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101129/001479.html b/zarb-ml/mageia-dev/20101129/001479.html new file mode 100644 index 000000000..6fa7e0db8 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001479.html @@ -0,0 +1,355 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129002441.GB2419%40sisay.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + + <LINK REL="Next" HREF="001484.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Michael scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129002441.GB2419%40sisay.ephaone.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">misc at zarb.org + </A><BR> + <I>Mon Nov 29 01:24:42 CET 2010</I> + <P><UL> + + <LI>Next message: <A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1479">[ date ]</a> + <a href="thread.html#1479">[ thread ]</a> + <a href="subject.html#1479">[ subject ]</a> + <a href="author.html#1479">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Sat, Nov 27, 2010 at 08:00:17PM +0200, Thomas Backlund wrote: +><i> Michael scherer skrev 27.11.2010 10:43: +</I>><i> >On Fri, Nov 26, 2010 at 10:29:14PM +0200, Thomas Backlund wrote: +</I>><i> [...] +</I>><i> > > +</I>><i> > > Then we come to the "problematic" part: +</I>><i> > +</I>><i> >This part look really too complex to me. +</I>><i> > +</I>><i> > > ------ +</I>><i> > > /x86_64/ +</I>><i> > > /media/ +</I>><i> > > /codecs/ (disabled by default) +</I>><i> > +</I>><i> > so, ogg, webm, being codec, should go there or not ? +</I>><i> > What about patents problem about something else than codec ? +</I>><i> > ( freetype, image such as gif, DRM stuff ) +</I>><i> > +</I>><i> +</I>><i> Actually this is the "maybe_legal_greyzone" repo, +</I>><i> but since flagging it as "codecs" would really make people +</I>><i> react, I named it so for now... +</I> +Sorry to be so direct, but that's doesn't answer the question :/ + +><i> > > /core/ (old main+contrib) +</I>><i> > > /backports/ (disabled by default) +</I>><i> > > /backports_testing/ (disabled by default) +</I>><i> > > /release/ +</I>><i> > > /testing/ (disabled by default) +</I> +Shall I suggest to name this one "updates_testing", for consistency ? +( consistency with backport_testing, and because this explain what goes in +more clearly. This also look simpler ). + +><i> > > /updates/ +</I>><i> > > /extra/ (unmaintained, disabled by default) +</I>><i> > +</I>><i> > If used by people, then why no one step to maintain anything ? +</I>><i> +</I>><i> Yeah, thats the problem. +</I> +If this is the problem, how does it help to have people to maintain +the application ? + +So far, the only way that really work is +"someone take care or we shoot the do^W rpm". +So maybe we could just be more active with cleaning ? + +><i> And reality shows we have a lot of packages assigned to nomaintainer@ ... +</I>><i> +</I>><i> > > /firmware/ (disabled by default) +</I>><i> > +</I>><i> > Why separate firmware from non_free ? What does it bring ? +</I>><i> > Since both of them are disabled by default, they can be simply merged. +</I>><i> > +</I>><i> +</I>><i> Well, this suggestion is partly based on the fact that we have users +</I>><i> that want a firmware free install, wich this would satisfy... +</I> +I do not think this warrant a full media, maybe just a way to filter package. + +Using a media seems overkill to me, since this bring complexity in dialog box, from +easyurpmi to rpmdrake and installer, and since it bring complexity on mirror, on BS +and on our policy. + +Maybe we could find a way to tag them "firmware", like a rpmgroup. + +The benefit is the complexity will only be on rpmdrake side, not on mirroring and BS +side. + +More ever, this would much more flexible ( ie, see the games option I propose later ). + +><i> But yes, if we ignore those suggestions, we split the firmwares in +</I>><i> GPL -> /core/ and the rest to /non-free/ +</I>><i> +</I>><i> > > /games/ (disabled by default) +</I>><i> > +</I>><i> > That's a simplification that make no sense. +</I>><i> > Not all games are big, not all big packages are games ( tetex, openoffice ). +</I>><i> +</I>><i> It's not only a size question, its also a nice option for companies +</I>><i> to not mirror games ("employees should work, not play...") +</I> +Such companies likely already have admins to prevent users from installing games. +Maybe we could add feature in rpmdrake for that ( like "do not show package +that match such conditions : group =~ games/, maintainer =~ nomaintainer@, requires =~ python ). + +The problem of private internal companies mirrors is really not our concern. +And their software policy, even if they may decide to apply it on a public mirror, +should not leak on our side. + +><i> And we have some contributors that already have stated that they +</I>><i> plan to add all possible games so it will grow. +</I>><i> and we all know games are the fastest growing /space demanding... +</I> +Well, so either that will cause a problem on our side, in which case this will +just be unhelpful on our primary mirrors, or it will only cause issues on some mirrors, +and in this case, there is lots of other thing that can take space that we do not +take in account : +- debug +- source code ( except that a GPL requirement ) +- adding another arch ( like arm/mips ) +- adding more iso ( something that is asked each time, like 64 bits one, etc ) + +So if we decide "mirrors will not handle the load, so we need to split games", then we +should also say "mirrors will not handle the load, so we need to do less iso/offer to not +mirror debug/offer to not mirror some architecture", and we end with a non consistent +network of mirror, with lots of complexity on our side to handle the possible choice +made by mirrors. I am not sure that users +will truly benefit from this. And I am sure that we will not benefit from the complexity. + +If the space is a issue ( and I think that's one of the main one ), then we should decide +based on metrics. Ie, we plan to have no more than X% growth in mirror size for 1 year. +If we hit some soft limit, then we investigate and decide ( ie, stop adding big backport, +stop adding new package, etc ). + +And decide the metrics based on mirrors input, and based on packagers input. +But so far, apart from Olivier and Wolfgang, we do not have much metrics and +requirements :/ + +><i> > > /non-free/ (disabled by default) +</I>><i> > > /debug_*/ (disabled by default) +</I>><i> > +</I>><i> > +</I>><i> > And what are the relation of requirements ? +</I>><i> > Ie, what can requires non_free, codecs, games, etc ? +</I>><i> > +</I>><i> +</I>><i> IMHO /core/ should be selfcontained. +</I>><i> We are promoting open source after all. +</I> +Yes, but what about the others ? +Ie, can a game requires a codec or not ? a package in extra ? +If we remove a package from extra, do we remove everything +that requires it ? + +><i> > And what about something that can goes in both media, ie a non_free +</I>><i> > game goes where ? A unmaintained codecs goes where ? +</I>><i> +</I>><i> Yeah, to be precise, that would need a games_non-free +</I> +another media ? Really, I think most users are already lost with the +current media selection. +For core, we have 15/20 medias ( src + debug + binary ( 1 or 2 ) * update/release/testing/backport/ +backport testing ). Each media we add at the level of core will therefore add 15 to 20 medias too. +So firmware, game, extras, codecs, non_free, that would make the total around 80 to 90 medias for a single +arch ( I assume that firmware may not have debug_* ) + +While it can be partially solved with a better interface for selecting media, +we cannot do miracles if there is too much things :/ + +So let's try to think how we can reduce the number of media. + +We have 2 kind of issue we try to solve at mirror level : +- the concern of mirror admins +- the concern of users. +with impact on BS and packagers + +Mirror admins are concerned by : +- size and growth ( see Wobo mail in the past thread ) +- content ( or at least, we think ) + +Content part is mainly legal matter, but I didn't heard any admin +telling "we can't do that", so that's my interpretation. The concern is +mainly around DCMA and EUCD, even if lesser know laws also exist around +the world ( like the Paragraph 202C of German law, who ban "hacking tools" ). +For DMCA, there is some protection for them : +<A HREF="http://www.benedict.com/Digital/Internet/DMCA/DMCA-SafeHarbor.aspx">http://www.benedict.com/Digital/Internet/DMCA/DMCA-SafeHarbor.aspx</A> . +For EUCD and the rest, I do not know. + + +Users are concerned with a wide range of issues, some contradictory : +- some want newer stuff, some don't +- some want stable stuff, some do not care as much +- some want non_free, some don't want it +- some want firmware, some don't +- etc + +Yet, the users concern mainly evolve around 2 things : +- package availiability +- package filtering, based on packages content + +The first part is already solved by the subdivision ( release, etc ). We +need to split them for build reason. So we can't really avoid adding +medias on this part. + +The second part is more tricky. And in fact, I think we can avoid creating media +for this. Ie, do not let the concern of filtering appearing on +the BS and mirrors, and push this on endusers system. +Some people do not want firmware on their system, they do not really care about +the firmware being in a separate directory on mirrors, as long as they can +disable them easily from the list of package they can install ( at +perl-urpm level, IMHO ). + +Same goes for non_free, or for nomaintained software. Or even games. + +So if we push the users issues on endusers system, we only have to manage the +mirror admins issue on mirror. + +And so here is a proposal that start by the size issue : + +- discuss with mirror admin, decide on a size that everybody would agree to mirror +for core/ for the next release, or the 2 next one. Ie, every year or every 6 months, +we do a survey of our mirrors, to see if everything goes well for them. +- discuss also of the growth of core in term of size +- decide on a limit size +- if anything goes off limit for mirror, add a overflow/ to hold the packages +that will not be mirrored by everybody. Overflow will be treated like core, in all points. +Only difference is that mirroring is optional ( but strongly encouraged ) +- put everything in core, except what goes to overflow. +- let users filter on their system, with something urpmi side ( I suggest a filtering +when we do urpmi.update, but the exact details of how to do it are not relevent now ). + +Overflow will be filled with packages that : +1) are not required by anything else ( thus games data would likely fit, +but not only ) +2) have triggered the limit of size + +After the limit of core size is raised ( ie after all mirror have agreed ),we can readd packages +from overflow to core, based on +criteria not defined yet ( first come first serve, try to make most useful first ? +or some wild guesstimate based on some mirrors stats ? ). But being in core or +overflow should not change anything for both enduser and packagers. This is +a mirror only concern, and so should be kept there only. +And this should avoid discussion about the location of packages by packagers. + +This mean that both core and overflow should be by default on users system. +( and I would not be against a better name, but I didn't found one ) + + + +In order to reduce number of media, another question is : +- should non_free have it own media ? + +Having them in core would simplify the BS, the upload and the mirroring. + +Having it separated would be better from various points of view ( political, +communication, etc ). Maybe some people will refuse to help us if we don't, +maybe there is some further restriction on some non-free software leading us +to create another media whatever we do, I do not know. +To me, as long as we can filter on user side, it would be ok. + +I cannot really tell what I prefer for that :/ + + +So the only important mirror issue left to solve is the greyzone area. +And well, that's quite complex. + +So we can either : + +1) decide to not care ( ie everything in core ) +2) decide to not offer them at all ( aka offload to PLF ) +3) decide to add a media ( aka the "codecs" media ) + +1 is the simplest. But maybe not really a good idea. + +If we care, then what indeed should be done is another media, and let admins +choose to mirrors it or not. I would even propose to revise the idea of +separation every year, because if all mirrors have the +2 medias, no need to split in reality ( but I doubt it will happen, but +at least, this would show that we try to revise our fondation on a regular +basis ). And at least, we should revise the packages present in such medias. +If there is some packages that can be moved to core, +then they should. + +We could also simplify a bit the BS by placing non-free packages there +( instead of either having a non_free media, or the non_free pacakges in core ). +It would sadden me a little to blur the line between "free with patents problems" +from "non free", but my PLF experience showed that most people do not care, and that +it requires more than a media separation. + +So, in the end, we would have : + +core/ + release + updates + updates_testing + backports + backports_testing + +"overflow"/ <- big packages, just for mirroring issues +restricted/ <- with non_free, firmware, "codecs" + +with the 5 directories under them, and with src, debug, binary. +Imho, 3 upper medias is the simplest we can have ( besides debug/src, that +I would place also on the same level than the binaries, but my +mail is already long enough :/ ) + +><i> For codecs either a extra_codecs or simply drop after a grace period. +</I>><i> but I guess codecs are important to people, so hopefully they wont +</I>><i> get orphaned... +</I> +Unfortunately, there is not always a relation between "being important +to users" and "someone want to take the burden of maintaining it" :/ +For example, something like etherpad would be nice for users, +yet no one will take time to maintain it. + +-- +Michael Scherer +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + + <LI>Next message: <A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1479">[ date ]</a> + <a href="thread.html#1479">[ thread ]</a> + <a href="subject.html#1479">[ subject ]</a> + <a href="author.html#1479">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001480.html b/zarb-ml/mageia-dev/20101129/001480.html new file mode 100644 index 000000000..167bcb349 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001480.html @@ -0,0 +1,94 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129004535.GV7479%40virgo.home.nanardon.zarb.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001492.html"> + <LINK REL="Next" HREF="001518.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Olivier Thauvin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129004535.GV7479%40virgo.home.nanardon.zarb.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">nanardon at nanardon.zarb.org + </A><BR> + <I>Mon Nov 29 01:45:35 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001492.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001518.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1480">[ date ]</a> + <a href="thread.html#1480">[ thread ]</a> + <a href="subject.html#1480">[ subject ]</a> + <a href="author.html#1480">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>* Renaud MICHEL (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">r.h.michel+mageia at gmail.com</A>) wrote: +><i> On samedi 27 novembre 2010 at 00:02, Maarten Vanraes wrote : +</I>><i> If the files are identical, they can be hard linked, and then the mirrors +</I>><i> updates them with rsync -aH. +</I>><i> (by the way, the readme already ask for those options +</I>><i> <A HREF="http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/mirror.readme">http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/mirror.readme</A> ) +</I>><i> It is quite easy to make a script that will make those hard links "à +</I>><i> posteriori" (you only need to compare files with identical names) +</I> +If you compare only the filename you'll probably link different file. To +do this you need at least to compare also the size. +But even if you take into account the size nothing warranty file are +really the same. Think to md5sum files, an md5 has fixed size and +filename will probably also have same lenght. + +I did a script to do this, this script check the md5 of +files before linking them to avoid mistake. + +BTW: I am not sure rsync fix hard link afterward. + +-- + +Olivier Thauvin +CNRS - LATMOS +♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20101129/0ff30e28/attachment-0001.asc> +</PRE> + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001492.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001518.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1480">[ date ]</a> + <a href="thread.html#1480">[ thread ]</a> + <a href="subject.html#1480">[ subject ]</a> + <a href="author.html#1480">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001481.html b/zarb-ml/mageia-dev/20101129/001481.html new file mode 100644 index 000000000..2c549e748 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001481.html @@ -0,0 +1,95 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1290991898.8266.9.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001518.html"> + <LINK REL="Next" HREF="001486.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1290991898.8266.9.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">misc at zarb.org + </A><BR> + <I>Mon Nov 29 01:51:38 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001518.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001486.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1481">[ date ]</a> + <a href="thread.html#1481">[ thread ]</a> + <a href="subject.html#1481">[ subject ]</a> + <a href="author.html#1481">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le dimanche 28 novembre 2010 à 22:12 +0200, Thomas Backlund a écrit : + +><i> So the mirror medias accordingly to all comments so far would be a simple: +</I>><i> +</I>><i> * core +</I>><i> - enabled by default +</I>><i> - mirrors must mirror this media to be listed as a mirror +</I>><i> - only GPL stuff +</I>><i> - must be selfcontained +</I>><i> +</I>><i> * nonfree +</I>><i> - disabled by default, installer will ask to enable it if +</I>><i> it detects hw that need driver/fw from here... +</I>><i> - mirrors must mirror this media to be listed as a mirror +</I>><i> - contains apps/drivers/firmware that are free to redistribute, +</I>><i> but we dont have GPL source for +</I>><i> - for example ati/nvidia drivers/firmware, Oracle Java, ... +</I>><i> +</I>><i> * tainted +</I>><i> - disabled by default +</I>><i> - mirrors are free to not mirror this media +</I>><i> - stuff we think we can redistribute, but that may have some +</I>><i> patent issues or other restrictions in oter countries. +</I> +damned, if I had seen this mail sooner, I would not have written my 200 +lines one ( that took 36 hours to write ). + +I agree with this split. + +-- +Michael Scherer + +</PRE> + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001518.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001486.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1481">[ date ]</a> + <a href="thread.html#1481">[ thread ]</a> + <a href="subject.html#1481">[ subject ]</a> + <a href="author.html#1481">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001482.html b/zarb-ml/mageia-dev/20101129/001482.html new file mode 100644 index 000000000..14107a7bd --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001482.html @@ -0,0 +1,112 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129010613.GW7479%40virgo.home.nanardon.zarb.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001486.html"> + <LINK REL="Next" HREF="001483.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Olivier Thauvin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129010613.GW7479%40virgo.home.nanardon.zarb.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">nanardon at nanardon.zarb.org + </A><BR> + <I>Mon Nov 29 02:06:13 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001486.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001483.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1482">[ date ]</a> + <a href="thread.html#1482">[ thread ]</a> + <a href="subject.html#1482">[ subject ]</a> + <a href="author.html#1482">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>* Thomas Backlund (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">tmb at iki.fi</A>) wrote: +><i> +</I>><i> So the mirror medias accordingly to all comments so far would be a simple: +</I>><i> +</I>><i> * core +</I>><i> - enabled by default +</I>><i> - mirrors must mirror this media to be listed as a mirror +</I>><i> - only GPL stuff +</I>><i> - must be selfcontained +</I>><i> +</I>><i> * nonfree +</I>><i> - disabled by default, installer will ask to enable it if +</I>><i> it detects hw that need driver/fw from here... +</I>><i> - mirrors must mirror this media to be listed as a mirror +</I>><i> - contains apps/drivers/firmware that are free to redistribute, +</I>><i> but we dont have GPL source for +</I>><i> - for example ati/nvidia drivers/firmware, Oracle Java, ... +</I>><i> +</I>><i> * tainted +</I>><i> - disabled by default +</I>><i> - mirrors are free to not mirror this media +</I>><i> - stuff we think we can redistribute, but that may have some +</I>><i> patent issues or other restrictions in oter countries. +</I>><i> +</I> +I can't agree with the "mirrors are free to not mirror this media", +three reasons: +1) I don't see an easy and safe way for mirrors to exclude a media (a +directory + hdlist in media/media_info) in each distribution, +2) I don't know how urpmi can manage this, all medias are described in +only one file, to detect something is missing +(media/media_info/media.cfg). +3) I tried to act as rules that a valid is a mirror containing +everything, to not have to deal with a lot of mirrors style. + +Regards. + +-- + +Olivier Thauvin +CNRS - LATMOS +♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20101129/6cfc08ef/attachment.asc> +</PRE> + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001486.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001483.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1482">[ date ]</a> + <a href="thread.html#1482">[ thread ]</a> + <a href="subject.html#1482">[ subject ]</a> + <a href="author.html#1482">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001483.html b/zarb-ml/mageia-dev/20101129/001483.html new file mode 100644 index 000000000..262213f98 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001483.html @@ -0,0 +1,81 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3CAANLkTi%3DTrFo74tS3dx21fExHW_3fURMn9gQq4OKyg8Rh%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="001482.html"> + <LINK REL="Next" HREF="001487.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Hoyt Duff</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3CAANLkTi%3DTrFo74tS3dx21fExHW_3fURMn9gQq4OKyg8Rh%40mail.gmail.com%3E" + TITLE="[Mageia-dev] Mirror layout, round two">hoytduff at gmail.com + </A><BR> + <I>Mon Nov 29 02:26:16 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001482.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001487.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1483">[ date ]</a> + <a href="thread.html#1483">[ thread ]</a> + <a href="subject.html#1483">[ subject ]</a> + <a href="author.html#1483">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Sun, Nov 28, 2010 at 8:06 PM, Olivier Thauvin +<<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">nanardon at nanardon.zarb.org</A>> wrote: + +><i> +</I>><i> I can't agree with the "mirrors are free to not mirror this media", +</I>><i> three reasons: +</I> + + +The "tainted" repository is analogous to the current PLF repository, no? + +Why can't Mageia handle it the same way? Then it does not have to be +included in any official mirrors. + + +-- +Hoyt +</PRE> + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001482.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001487.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1483">[ date ]</a> + <a href="thread.html#1483">[ thread ]</a> + <a href="subject.html#1483">[ subject ]</a> + <a href="author.html#1483">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001484.html b/zarb-ml/mageia-dev/20101129/001484.html new file mode 100644 index 000000000..137c25ebf --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001484.html @@ -0,0 +1,379 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011290233.29098.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="001479.html"> + <LINK REL="Next" HREF="001488.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Maarten Vanraes</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011290233.29098.maarten.vanraes%40gmail.com%3E" + TITLE="[Mageia-dev] Mirror layout, round two">maarten.vanraes at gmail.com + </A><BR> + <I>Mon Nov 29 02:33:29 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001479.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001488.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1484">[ date ]</a> + <a href="thread.html#1484">[ thread ]</a> + <a href="subject.html#1484">[ subject ]</a> + <a href="author.html#1484">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op maandag 29 november 2010 01:24:42 schreef Michael scherer: +><i> On Sat, Nov 27, 2010 at 08:00:17PM +0200, Thomas Backlund wrote: +</I>><i> > Michael scherer skrev 27.11.2010 10:43: +</I>><i> > >On Fri, Nov 26, 2010 at 10:29:14PM +0200, Thomas Backlund wrote: +</I>><i> > [...] +</I>><i> > +</I>><i> > > > Then we come to the "problematic" part: +</I>><i> > >This part look really too complex to me. +</I>><i> > > +</I>><i> > > > ------ +</I>><i> > > > /x86_64/ +</I>><i> > > > +</I>><i> > > > /media/ +</I>><i> > > > +</I>><i> > > > /codecs/ (disabled by default) +</I>><i> > > +</I>><i> > > so, ogg, webm, being codec, should go there or not ? +</I>><i> > > What about patents problem about something else than codec ? +</I>><i> > > ( freetype, image such as gif, DRM stuff ) +</I>><i> > +</I>><i> > Actually this is the "maybe_legal_greyzone" repo, +</I>><i> > but since flagging it as "codecs" would really make people +</I>><i> > react, I named it so for now... +</I>><i> +</I>><i> Sorry to be so direct, but that's doesn't answer the question :/ +</I>><i> +</I>><i> > > > /core/ (old main+contrib) +</I>><i> > > > +</I>><i> > > > /backports/ (disabled by default) +</I>><i> > > > /backports_testing/ (disabled by default) +</I>><i> > > > /release/ +</I>><i> > > > /testing/ (disabled by default) +</I>><i> +</I>><i> Shall I suggest to name this one "updates_testing", for consistency ? +</I>><i> ( consistency with backport_testing, and because this explain what goes in +</I>><i> more clearly. This also look simpler ). +</I>><i> +</I>><i> > > > /updates/ +</I>><i> > > > +</I>><i> > > > /extra/ (unmaintained, disabled by default) +</I>><i> > > +</I>><i> > > If used by people, then why no one step to maintain anything ? +</I>><i> > +</I>><i> > Yeah, thats the problem. +</I>><i> +</I>><i> If this is the problem, how does it help to have people to maintain +</I>><i> the application ? +</I>><i> +</I>><i> So far, the only way that really work is +</I>><i> "someone take care or we shoot the do^W rpm". +</I>><i> So maybe we could just be more active with cleaning ? +</I>><i> +</I>><i> > And reality shows we have a lot of packages assigned to nomaintainer@ ... +</I>><i> > +</I>><i> > > > /firmware/ (disabled by default) +</I>><i> > > +</I>><i> > > Why separate firmware from non_free ? What does it bring ? +</I>><i> > > Since both of them are disabled by default, they can be simply merged. +</I>><i> > +</I>><i> > Well, this suggestion is partly based on the fact that we have users +</I>><i> > that want a firmware free install, wich this would satisfy... +</I>><i> +</I>><i> I do not think this warrant a full media, maybe just a way to filter +</I>><i> package. +</I>><i> +</I>><i> Using a media seems overkill to me, since this bring complexity in dialog +</I>><i> box, from easyurpmi to rpmdrake and installer, and since it bring +</I>><i> complexity on mirror, on BS and on our policy. +</I>><i> +</I>><i> Maybe we could find a way to tag them "firmware", like a rpmgroup. +</I>><i> +</I>><i> The benefit is the complexity will only be on rpmdrake side, not on +</I>><i> mirroring and BS side. +</I>><i> +</I>><i> More ever, this would much more flexible ( ie, see the games option I +</I>><i> propose later ). +</I>><i> +</I>><i> > But yes, if we ignore those suggestions, we split the firmwares in +</I>><i> > GPL -> /core/ and the rest to /non-free/ +</I>><i> > +</I>><i> > > > /games/ (disabled by default) +</I>><i> > > +</I>><i> > > That's a simplification that make no sense. +</I>><i> > > Not all games are big, not all big packages are games ( tetex, +</I>><i> > > openoffice ). +</I>><i> > +</I>><i> > It's not only a size question, its also a nice option for companies +</I>><i> > to not mirror games ("employees should work, not play...") +</I>><i> +</I>><i> Such companies likely already have admins to prevent users from installing +</I>><i> games. Maybe we could add feature in rpmdrake for that ( like "do not show +</I>><i> package that match such conditions : group =~ games/, maintainer =~ +</I>><i> nomaintainer@, requires =~ python ). +</I>><i> +</I>><i> The problem of private internal companies mirrors is really not our +</I>><i> concern. And their software policy, even if they may decide to apply it on +</I>><i> a public mirror, should not leak on our side. +</I>><i> +</I>><i> > And we have some contributors that already have stated that they +</I>><i> > plan to add all possible games so it will grow. +</I>><i> > and we all know games are the fastest growing /space demanding... +</I>><i> +</I>><i> Well, so either that will cause a problem on our side, in which case this +</I>><i> will just be unhelpful on our primary mirrors, or it will only cause +</I>><i> issues on some mirrors, and in this case, there is lots of other thing +</I>><i> that can take space that we do not take in account : +</I>><i> - debug +</I>><i> - source code ( except that a GPL requirement ) +</I>><i> - adding another arch ( like arm/mips ) +</I>><i> - adding more iso ( something that is asked each time, like 64 bits one, +</I>><i> etc ) +</I>><i> +</I>><i> So if we decide "mirrors will not handle the load, so we need to split +</I>><i> games", then we should also say "mirrors will not handle the load, so we +</I>><i> need to do less iso/offer to not mirror debug/offer to not mirror some +</I>><i> architecture", and we end with a non consistent network of mirror, with +</I>><i> lots of complexity on our side to handle the possible choice made by +</I>><i> mirrors. I am not sure that users +</I>><i> will truly benefit from this. And I am sure that we will not benefit from +</I>><i> the complexity. +</I>><i> +</I>><i> If the space is a issue ( and I think that's one of the main one ), then we +</I>><i> should decide based on metrics. Ie, we plan to have no more than X% growth +</I>><i> in mirror size for 1 year. If we hit some soft limit, then we investigate +</I>><i> and decide ( ie, stop adding big backport, stop adding new package, etc ). +</I>><i> +</I>><i> And decide the metrics based on mirrors input, and based on packagers +</I>><i> input. But so far, apart from Olivier and Wolfgang, we do not have much +</I>><i> metrics and requirements :/ +</I>><i> +</I>><i> > > > /non-free/ (disabled by default) +</I>><i> > > > /debug_*/ (disabled by default) +</I>><i> > > +</I>><i> > > And what are the relation of requirements ? +</I>><i> > > Ie, what can requires non_free, codecs, games, etc ? +</I>><i> > +</I>><i> > IMHO /core/ should be selfcontained. +</I>><i> > We are promoting open source after all. +</I>><i> +</I>><i> Yes, but what about the others ? +</I>><i> Ie, can a game requires a codec or not ? a package in extra ? +</I>><i> If we remove a package from extra, do we remove everything +</I>><i> that requires it ? +</I>><i> +</I>><i> > > And what about something that can goes in both media, ie a non_free +</I>><i> > > game goes where ? A unmaintained codecs goes where ? +</I>><i> > +</I>><i> > Yeah, to be precise, that would need a games_non-free +</I>><i> +</I>><i> another media ? Really, I think most users are already lost with the +</I>><i> current media selection. +</I>><i> For core, we have 15/20 medias ( src + debug + binary ( 1 or 2 ) * +</I>><i> update/release/testing/backport/ backport testing ). Each media we add at +</I>><i> the level of core will therefore add 15 to 20 medias too. So firmware, +</I>><i> game, extras, codecs, non_free, that would make the total around 80 to 90 +</I>><i> medias for a single arch ( I assume that firmware may not have debug_* ) +</I>><i> +</I>><i> While it can be partially solved with a better interface for selecting +</I>><i> media, we cannot do miracles if there is too much things :/ +</I>><i> +</I>><i> So let's try to think how we can reduce the number of media. +</I>><i> +</I>><i> We have 2 kind of issue we try to solve at mirror level : +</I>><i> - the concern of mirror admins +</I>><i> - the concern of users. +</I>><i> with impact on BS and packagers +</I>><i> +</I>><i> Mirror admins are concerned by : +</I>><i> - size and growth ( see Wobo mail in the past thread ) +</I>><i> - content ( or at least, we think ) +</I>><i> +</I>><i> Content part is mainly legal matter, but I didn't heard any admin +</I>><i> telling "we can't do that", so that's my interpretation. The concern is +</I>><i> mainly around DCMA and EUCD, even if lesser know laws also exist around +</I>><i> the world ( like the Paragraph 202C of German law, who ban "hacking tools" +</I>><i> ). For DMCA, there is some protection for them : +</I>><i> <A HREF="http://www.benedict.com/Digital/Internet/DMCA/DMCA-SafeHarbor.aspx">http://www.benedict.com/Digital/Internet/DMCA/DMCA-SafeHarbor.aspx</A> . +</I>><i> For EUCD and the rest, I do not know. +</I>><i> +</I>><i> +</I>><i> Users are concerned with a wide range of issues, some contradictory : +</I>><i> - some want newer stuff, some don't +</I>><i> - some want stable stuff, some do not care as much +</I>><i> - some want non_free, some don't want it +</I>><i> - some want firmware, some don't +</I>><i> - etc +</I>><i> +</I>><i> Yet, the users concern mainly evolve around 2 things : +</I>><i> - package availiability +</I>><i> - package filtering, based on packages content +</I>><i> +</I>><i> The first part is already solved by the subdivision ( release, etc ). We +</I>><i> need to split them for build reason. So we can't really avoid adding +</I>><i> medias on this part. +</I>><i> +</I>><i> The second part is more tricky. And in fact, I think we can avoid creating +</I>><i> media for this. Ie, do not let the concern of filtering appearing on +</I>><i> the BS and mirrors, and push this on endusers system. +</I>><i> Some people do not want firmware on their system, they do not really care +</I>><i> about the firmware being in a separate directory on mirrors, as long as +</I>><i> they can disable them easily from the list of package they can install ( +</I>><i> at perl-urpm level, IMHO ). +</I>><i> +</I>><i> Same goes for non_free, or for nomaintained software. Or even games. +</I>><i> +</I>><i> So if we push the users issues on endusers system, we only have to manage +</I>><i> the mirror admins issue on mirror. +</I>><i> +</I>><i> And so here is a proposal that start by the size issue : +</I>><i> +</I>><i> - discuss with mirror admin, decide on a size that everybody would agree to +</I>><i> mirror for core/ for the next release, or the 2 next one. Ie, every year +</I>><i> or every 6 months, we do a survey of our mirrors, to see if everything +</I>><i> goes well for them. - discuss also of the growth of core in term of size +</I>><i> - decide on a limit size +</I>><i> - if anything goes off limit for mirror, add a overflow/ to hold the +</I>><i> packages that will not be mirrored by everybody. Overflow will be treated +</I>><i> like core, in all points. Only difference is that mirroring is optional ( +</I>><i> but strongly encouraged ) - put everything in core, except what goes to +</I>><i> overflow. +</I>><i> - let users filter on their system, with something urpmi side ( I suggest a +</I>><i> filtering when we do urpmi.update, but the exact details of how to do it +</I>><i> are not relevent now ). +</I>><i> +</I>><i> Overflow will be filled with packages that : +</I>><i> 1) are not required by anything else ( thus games data would likely fit, +</I>><i> but not only ) +</I>><i> 2) have triggered the limit of size +</I>><i> +</I>><i> After the limit of core size is raised ( ie after all mirror have agreed +</I>><i> ),we can readd packages from overflow to core, based on +</I>><i> criteria not defined yet ( first come first serve, try to make most useful +</I>><i> first ? or some wild guesstimate based on some mirrors stats ? ). But +</I>><i> being in core or overflow should not change anything for both enduser and +</I>><i> packagers. This is a mirror only concern, and so should be kept there +</I>><i> only. +</I>><i> And this should avoid discussion about the location of packages by +</I>><i> packagers. +</I>><i> +</I>><i> This mean that both core and overflow should be by default on users system. +</I>><i> ( and I would not be against a better name, but I didn't found one ) +</I>><i> +</I>><i> +</I>><i> +</I>><i> In order to reduce number of media, another question is : +</I>><i> - should non_free have it own media ? +</I>><i> +</I>><i> Having them in core would simplify the BS, the upload and the mirroring. +</I>><i> +</I>><i> Having it separated would be better from various points of view ( +</I>><i> political, communication, etc ). Maybe some people will refuse to help us +</I>><i> if we don't, maybe there is some further restriction on some non-free +</I>><i> software leading us to create another media whatever we do, I do not know. +</I>><i> To me, as long as we can filter on user side, it would be ok. +</I>><i> +</I>><i> I cannot really tell what I prefer for that :/ +</I>><i> +</I>><i> +</I>><i> So the only important mirror issue left to solve is the greyzone area. +</I>><i> And well, that's quite complex. +</I>><i> +</I>><i> So we can either : +</I>><i> +</I>><i> 1) decide to not care ( ie everything in core ) +</I>><i> 2) decide to not offer them at all ( aka offload to PLF ) +</I>><i> 3) decide to add a media ( aka the "codecs" media ) +</I>><i> +</I>><i> 1 is the simplest. But maybe not really a good idea. +</I>><i> +</I>><i> If we care, then what indeed should be done is another media, and let +</I>><i> admins choose to mirrors it or not. I would even propose to revise the +</I>><i> idea of separation every year, because if all mirrors have the +</I>><i> 2 medias, no need to split in reality ( but I doubt it will happen, but +</I>><i> at least, this would show that we try to revise our fondation on a regular +</I>><i> basis ). And at least, we should revise the packages present in such +</I>><i> medias. If there is some packages that can be moved to core, +</I>><i> then they should. +</I>><i> +</I>><i> We could also simplify a bit the BS by placing non-free packages there +</I>><i> ( instead of either having a non_free media, or the non_free pacakges in +</I>><i> core ). It would sadden me a little to blur the line between "free with +</I>><i> patents problems" from "non free", but my PLF experience showed that most +</I>><i> people do not care, and that it requires more than a media separation. +</I>><i> +</I>><i> So, in the end, we would have : +</I>><i> +</I>><i> core/ +</I>><i> release +</I>><i> updates +</I>><i> updates_testing +</I>><i> backports +</I>><i> backports_testing +</I>><i> +</I>><i> "overflow"/ <- big packages, just for mirroring issues +</I>><i> restricted/ <- with non_free, firmware, "codecs" +</I>><i> +</I>><i> with the 5 directories under them, and with src, debug, binary. +</I>><i> Imho, 3 upper medias is the simplest we can have ( besides debug/src, that +</I>><i> I would place also on the same level than the binaries, but my +</I>><i> mail is already long enough :/ ) +</I>><i> +</I>><i> > For codecs either a extra_codecs or simply drop after a grace period. +</I>><i> > but I guess codecs are important to people, so hopefully they wont +</I>><i> > get orphaned... +</I>><i> +</I>><i> Unfortunately, there is not always a relation between "being important +</I>><i> to users" and "someone want to take the burden of maintaining it" :/ +</I>><i> For example, something like etherpad would be nice for users, +</I>><i> yet no one will take time to maintain it. +</I> +I agree with you partly (mostly on the basis that mirror setup should be +primarily for mirror admins), however: + - some of those big packages are pretty much core + - and a big core repos is having a big hdlists as well; and you should take +into consideration that some people have regular phone line internet. + - i'm not entirely sure that mirror admins would like the overflow idea: + - if you're a small public mirror (ie: storage size), you would not mirror +the overflow; however some big packages would be pretty essential. seperating +extra (unmaintained pacakages); and games would seem easier; also on the +following up side; (ie: when problems arise); also a point is what about those +big packages and their dependencies (or rather other packages which depend on +it). + - i don't believe unmaintained packages is something that can be avoided +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001479.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001488.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1484">[ date ]</a> + <a href="thread.html#1484">[ thread ]</a> + <a href="subject.html#1484">[ subject ]</a> + <a href="author.html#1484">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001485.html b/zarb-ml/mageia-dev/20101129/001485.html new file mode 100644 index 000000000..4e1938ab3 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001485.html @@ -0,0 +1,113 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011290239.56255.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="001487.html"> + <LINK REL="Next" HREF="001490.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Maarten Vanraes</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011290239.56255.maarten.vanraes%40gmail.com%3E" + TITLE="[Mageia-dev] Mirror layout, round two">maarten.vanraes at gmail.com + </A><BR> + <I>Mon Nov 29 02:39:56 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001487.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001490.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1485">[ date ]</a> + <a href="thread.html#1485">[ thread ]</a> + <a href="subject.html#1485">[ subject ]</a> + <a href="author.html#1485">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op maandag 29 november 2010 02:06:13 schreef Olivier Thauvin: +><i> * Thomas Backlund (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">tmb at iki.fi</A>) wrote: +</I>><i> > So the mirror medias accordingly to all comments so far would be a +</I>><i> > simple: +</I>><i> > +</I>><i> > * core +</I>><i> > +</I>><i> > - enabled by default +</I>><i> > - mirrors must mirror this media to be listed as a mirror +</I>><i> > - only GPL stuff +</I>><i> > - must be selfcontained +</I>><i> > +</I>><i> > * nonfree +</I>><i> > +</I>><i> > - disabled by default, installer will ask to enable it if +</I>><i> > +</I>><i> > it detects hw that need driver/fw from here... +</I>><i> > +</I>><i> > - mirrors must mirror this media to be listed as a mirror +</I>><i> > - contains apps/drivers/firmware that are free to redistribute, +</I>><i> > +</I>><i> > but we dont have GPL source for +</I>><i> > +</I>><i> > - for example ati/nvidia drivers/firmware, Oracle Java, ... +</I>><i> > +</I>><i> > * tainted +</I>><i> > +</I>><i> > - disabled by default +</I>><i> > - mirrors are free to not mirror this media +</I>><i> > - stuff we think we can redistribute, but that may have some +</I>><i> > +</I>><i> > patent issues or other restrictions in oter countries. +</I>><i> +</I>><i> I can't agree with the "mirrors are free to not mirror this media", +</I>><i> three reasons: +</I>><i> 1) I don't see an easy and safe way for mirrors to exclude a media (a +</I>><i> directory + hdlist in media/media_info) in each distribution, +</I>><i> 2) I don't know how urpmi can manage this, all medias are described in +</I>><i> only one file, to detect something is missing +</I>><i> (media/media_info/media.cfg). +</I>><i> 3) I tried to act as rules that a valid is a mirror containing +</I>><i> everything, to not have to deal with a lot of mirrors style. +</I>><i> +</I>><i> Regards. +</I> +actually, when i was working on my urpmi-proxy, i noticed that the media.cfg +file is easily changed (can be made to merge) + +and for this to work, we still need urpmi mirrorlist function that works well, +by just getting those from another mirror +</PRE> + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001487.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001490.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1485">[ date ]</a> + <a href="thread.html#1485">[ thread ]</a> + <a href="subject.html#1485">[ subject ]</a> + <a href="author.html#1485">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001486.html b/zarb-ml/mageia-dev/20101129/001486.html new file mode 100644 index 000000000..66f2f9d31 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001486.html @@ -0,0 +1,103 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011290242.58769.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="001481.html"> + <LINK REL="Next" HREF="001482.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Maarten Vanraes</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011290242.58769.maarten.vanraes%40gmail.com%3E" + TITLE="[Mageia-dev] Mirror layout, round two">maarten.vanraes at gmail.com + </A><BR> + <I>Mon Nov 29 02:42:58 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001481.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001482.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1486">[ date ]</a> + <a href="thread.html#1486">[ thread ]</a> + <a href="subject.html#1486">[ subject ]</a> + <a href="author.html#1486">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op maandag 29 november 2010 01:51:38 schreef Michael Scherer: +><i> Le dimanche 28 novembre 2010 à 22:12 +0200, Thomas Backlund a écrit : +</I>><i> > So the mirror medias accordingly to all comments so far would be a +</I>><i> > simple: +</I>><i> > +</I>><i> > * core +</I>><i> > +</I>><i> > - enabled by default +</I>><i> > - mirrors must mirror this media to be listed as a mirror +</I>><i> > - only GPL stuff +</I>><i> > - must be selfcontained +</I>><i> > +</I>><i> > * nonfree +</I>><i> > +</I>><i> > - disabled by default, installer will ask to enable it if +</I>><i> > +</I>><i> > it detects hw that need driver/fw from here... +</I>><i> > +</I>><i> > - mirrors must mirror this media to be listed as a mirror +</I>><i> > - contains apps/drivers/firmware that are free to redistribute, +</I>><i> > +</I>><i> > but we dont have GPL source for +</I>><i> > +</I>><i> > - for example ati/nvidia drivers/firmware, Oracle Java, ... +</I>><i> > +</I>><i> > * tainted +</I>><i> > +</I>><i> > - disabled by default +</I>><i> > - mirrors are free to not mirror this media +</I>><i> > - stuff we think we can redistribute, but that may have some +</I>><i> > +</I>><i> > patent issues or other restrictions in oter countries. +</I>><i> +</I>><i> damned, if I had seen this mail sooner, I would not have written my 200 +</I>><i> lines one ( that took 36 hours to write ). +</I>><i> +</I>><i> I agree with this split. +</I> +I can agree with this; however i think that: + - i would add extra with the unmaintained packages (and not remove them); +mirror would be free not to mirror that media as well and disabled by default + - core would be too big (mirror size + hdlists size + search time) (a games +split up is what i would recommend to alleviate this problem) +</PRE> + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001481.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001482.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1486">[ date ]</a> + <a href="thread.html#1486">[ thread ]</a> + <a href="subject.html#1486">[ subject ]</a> + <a href="author.html#1486">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001487.html b/zarb-ml/mageia-dev/20101129/001487.html new file mode 100644 index 000000000..8e66f1d0b --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001487.html @@ -0,0 +1,82 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1290998029.8266.17.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001483.html"> + <LINK REL="Next" HREF="001485.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1290998029.8266.17.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">misc at zarb.org + </A><BR> + <I>Mon Nov 29 03:33:49 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001483.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001485.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1487">[ date ]</a> + <a href="thread.html#1487">[ thread ]</a> + <a href="subject.html#1487">[ subject ]</a> + <a href="author.html#1487">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le dimanche 28 novembre 2010 à 20:26 -0500, Hoyt Duff a écrit : +><i> On Sun, Nov 28, 2010 at 8:06 PM, Olivier Thauvin +</I>><i> <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">nanardon at nanardon.zarb.org</A>> wrote: +</I>><i> +</I>><i> > +</I>><i> > I can't agree with the "mirrors are free to not mirror this media", +</I>><i> > three reasons: +</I>><i> +</I>><i> +</I>><i> +</I>><i> The "tainted" repository is analogous to the current PLF repository, no? +</I>><i> +</I>><i> Why can't Mageia handle it the same way? +</I> +Ie, handling nothing ? +That would mean duplicating the build system on another servers, +duplicating the mirroring system, and let users figure by themself what +they need to do ? + +-- +Michael Scherer + +</PRE> + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001483.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001485.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1487">[ date ]</a> + <a href="thread.html#1487">[ thread ]</a> + <a href="subject.html#1487">[ subject ]</a> + <a href="author.html#1487">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001488.html b/zarb-ml/mageia-dev/20101129/001488.html new file mode 100644 index 000000000..09b14989a --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001488.html @@ -0,0 +1,131 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1291000599.8266.44.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001484.html"> + <LINK REL="Next" HREF="001489.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1291000599.8266.44.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">misc at zarb.org + </A><BR> + <I>Mon Nov 29 04:16:39 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001489.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1488">[ date ]</a> + <a href="thread.html#1488">[ thread ]</a> + <a href="subject.html#1488">[ subject ]</a> + <a href="author.html#1488">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 29 novembre 2010 à 02:33 +0100, Maarten Vanraes a écrit : + +><i> > [ michael's long email ] +</I>><i> > +</I>><i> I agree with you partly (mostly on the basis that mirror setup should be +</I>><i> primarily for mirror admins), however: +</I>><i> - some of those big packages are pretty much core +</I> +The goal is not to place all big packages somewhere else. Just newer +packages that goes of the limit, even if they are not big. And by newer, +I mean "newer rpm", not "newer release of a existing packages". + +><i> - and a big core repos is having a big hdlists as well; and you should take +</I>><i> into consideration that some people have regular phone line internet. +</I> +Then, maybe a big index file is not a good idea. Using rsync + splitted +headers, like yum does, would maybe be more suitable for this situation +( nanar proposed this when we discussed of this some months ago while +eating pizza ). + +And in fact, bigger hdlists come from : +- having lots of package ( 10k by rpm, estimation of Olivier ) +- having lots of file ( 1k per file, same origin ) +- having lots of requires/provides ( even if this is likely negligible ) + +A package with a 100 mb file is taking less hdlist space ( around 10k ) +than a package with 100 files of 30k ( around 110k ). + +For exemple, on mandriva mirror, +kernel-kerriged-source header : 1.3mo, rpm 32 mo. +vegastrike-data header : 446ko, rpm 430 mo. + +And so, the explosion of kernel packages is likely a cause of contribs +hdlist size increase. On the 2010.1 stable mdv release, there is 28 +kernel or kernel-sources rpm, thus using around 28 mo in the 74 mo sized +hdlist, ie 33% ). + +Thus splitting games will not lead to a so big decrease of the hdlist. + + +><i> - i'm not entirely sure that mirror admins would like the overflow idea: +</I>><i> - if you're a small public mirror (ie: storage size), you would not mirror +</I>><i> the overflow; however some big packages would be pretty essential. seperating +</I>><i> extra (unmaintained packages); and games would seem easier; +</I> +Well, not mirroring is the goal of the overflow media, as explained. I +have already explained why games is not really a good idea, and why the +unmaintained idea is also not a good idea, so I will not repeat myself +( especially since you did it for me by not cleaning the mail before +responding :/ ). + +><i> also on the +</I>><i> following up side; (ie: when problems arise); also a point is what about those +</I>><i> big packages and their dependencies (or rather other packages which depend on +</I>><i> it). +</I> +That's why I said "there is no difference between core and overflow". +This mean "core can depend on overflow or core, overflow can depend on +core or overflow". And while a user could remove overflow, I do not +think one of the goal is to prevent people from doing stupid stuff +( like removing release, or disabling updates, for urpmi related +example ) + +><i> - i don't believe unmaintained packages is something that can be avoided +</I> +I do not think unmaintained packages is such a problem that everybody +seems to imply ( and the fact no one gave me any convincing stats or +data is not in favor of making me change my mind ). My own opinion is +that most people have seen on of their pet peeves not fixed because of +that, thus making the problem much more important in the eyes of each of +us than it is in reality. + +-- +Michael Scherer + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001489.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1488">[ date ]</a> + <a href="thread.html#1488">[ thread ]</a> + <a href="subject.html#1488">[ subject ]</a> + <a href="author.html#1488">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001489.html b/zarb-ml/mageia-dev/20101129/001489.html new file mode 100644 index 000000000..16016fbf1 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001489.html @@ -0,0 +1,123 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129033207.GX7479%40virgo.home.nanardon.zarb.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001488.html"> + <LINK REL="Next" HREF="001496.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Olivier Thauvin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129033207.GX7479%40virgo.home.nanardon.zarb.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">nanardon at nanardon.zarb.org + </A><BR> + <I>Mon Nov 29 04:32:07 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001488.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001496.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1489">[ date ]</a> + <a href="thread.html#1489">[ thread ]</a> + <a href="subject.html#1489">[ subject ]</a> + <a href="author.html#1489">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>* Maarten Vanraes (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">maarten.vanraes at gmail.com</A>) wrote: +><i> Op maandag 29 november 2010 01:24:42 schreef Michael scherer: +</I>><i> > So if we decide "mirrors will not handle the load, so we need to split +</I>><i> > games", then we should also say "mirrors will not handle the load, so we +</I>><i> > need to do less iso/offer to not mirror debug/offer to not mirror some +</I>><i> > architecture", and we end with a non consistent network of mirror, with +</I>><i> > lots of complexity on our side to handle the possible choice made by +</I>><i> > mirrors. I am not sure that users +</I> +The solution is quite simple: do not give the choice. + +For exemple, I am completly unable to know which part of Fedora or +Centos i can exclude, so I exclude nothing (espcially since none of this +distro said something can be excluded). + +><i> > will truly benefit from this. And I am sure that we will not benefit from +</I>><i> > the complexity. +</I>><i> > +</I>><i> > If the space is a issue ( and I think that's one of the main one ), then we +</I>><i> > should decide based on metrics. Ie, we plan to have no more than X% growth +</I>><i> > in mirror size for 1 year. If we hit some soft limit, then we investigate +</I>><i> > and decide ( ie, stop adding big backport, stop adding new package, etc ). +</I> +The space is an issue, but the distro size is increasing like everything +and like all distro. Disk size is also growing. + +The problem is the size of the global tree, not the size of a single +distro. I expect a 700 GB for Mageia, the distribution is far less than +that. + +><i> +</I>><i> I agree with you partly (mostly on the basis that mirror setup should be +</I>><i> primarily for mirror admins), however: +</I>><i> - some of those big packages are pretty much core +</I>><i> - and a big core repos is having a big hdlists as well; and you should take +</I>><i> into consideration that some people have regular phone line internet. +</I>><i> - i'm not entirely sure that mirror admins would like the overflow idea: +</I>><i> - if you're a small public mirror (ie: storage size), you would not mirror +</I>><i> the overflow; however some big packages would be pretty essential. seperating +</I>><i> extra (unmaintained pacakages); and games would seem easier; also on the +</I>><i> following up side; (ie: when problems arise); also a point is what about those +</I>><i> big packages and their dependencies (or rather other packages which depend on +</I>><i> it). +</I> +If you're maintaining a mirror you should first take care about the +ressources need by each distro you host, and small mirror won't probably +host mageia. +There enough big mirrors around the world able to host us to not +encourage small one to mirror us with bad practices, IMHO. + +Obviously, we (mirrors admin) have always the same question before +hosting a new tree: "how many space do you need" and "how many bandwidth +will be used". + +-- + +Olivier Thauvin +CNRS - LATMOS +♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20101129/2a00408a/attachment.asc> +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001488.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001496.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1489">[ date ]</a> + <a href="thread.html#1489">[ thread ]</a> + <a href="subject.html#1489">[ subject ]</a> + <a href="author.html#1489">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001490.html b/zarb-ml/mageia-dev/20101129/001490.html new file mode 100644 index 000000000..87b126617 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001490.html @@ -0,0 +1,108 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129034319.GY7479%40virgo.home.nanardon.zarb.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001485.html"> + <LINK REL="Next" HREF="001491.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Olivier Thauvin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129034319.GY7479%40virgo.home.nanardon.zarb.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">nanardon at nanardon.zarb.org + </A><BR> + <I>Mon Nov 29 04:43:19 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001485.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001491.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1490">[ date ]</a> + <a href="thread.html#1490">[ thread ]</a> + <a href="subject.html#1490">[ subject ]</a> + <a href="author.html#1490">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>* Maarten Vanraes (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">maarten.vanraes at gmail.com</A>) wrote: +><i> Op maandag 29 november 2010 02:06:13 schreef Olivier Thauvin: +</I>><i> > > - disabled by default +</I>><i> > > - mirrors are free to not mirror this media +</I>><i> > > - stuff we think we can redistribute, but that may have some +</I>><i> > > +</I>><i> > > patent issues or other restrictions in oter countries. +</I>><i> > +</I>><i> > I can't agree with the "mirrors are free to not mirror this media", +</I>><i> > three reasons: +</I>><i> > 1) I don't see an easy and safe way for mirrors to exclude a media (a +</I>><i> > directory + hdlist in media/media_info) in each distribution, +</I>><i> > 2) I don't know how urpmi can manage this, all medias are described in +</I>><i> > only one file, to detect something is missing +</I>><i> > (media/media_info/media.cfg). +</I>><i> > 3) I tried to act as rules that a valid is a mirror containing +</I>><i> > everything, to not have to deal with a lot of mirrors style. +</I>><i> > +</I>><i> > Regards. +</I>><i> +</I>><i> actually, when i was working on my urpmi-proxy, i noticed that the media.cfg +</I>><i> file is easily changed (can be made to merge) +</I>><i> +</I>><i> and for this to work, we still need urpmi mirrorlist function that works well, +</I>><i> by just getting those from another mirror +</I> +The main problem is not on urpmi side. How me (mirror admin) will +exclude such things in practice ? +Maybe a more direct approach is need: Can you write the rsync command +line I have to run on the mirror ? What will happend is one day Mageia +team to change the structure ? + +It's true this can be done on server side, but no mirror will sync from +rsync.mageia.org. So this have to be done on Tiers1 on which we have no +control (except distrib-coffee, a special case), and ibiblio sys admin +seem's to be very busy. + +-- + +Olivier Thauvin +CNRS - LATMOS +♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20101129/a63730f3/attachment.asc> +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001485.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001491.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1490">[ date ]</a> + <a href="thread.html#1490">[ thread ]</a> + <a href="subject.html#1490">[ subject ]</a> + <a href="author.html#1490">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001491.html b/zarb-ml/mageia-dev/20101129/001491.html new file mode 100644 index 000000000..ae3e1dcbb --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001491.html @@ -0,0 +1,126 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF35F01.7010507%40iki.fi%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001490.html"> + <LINK REL="Next" HREF="001500.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Thomas Backlund</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF35F01.7010507%40iki.fi%3E" + TITLE="[Mageia-dev] Mirror layout, round two">tmb at iki.fi + </A><BR> + <I>Mon Nov 29 09:06:25 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001490.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001500.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1491">[ date ]</a> + <a href="thread.html#1491">[ thread ]</a> + <a href="subject.html#1491">[ subject ]</a> + <a href="author.html#1491">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Olivier Thauvin skrev 29.11.2010 03:06: +><i> * Thomas Backlund (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">tmb at iki.fi</A>) wrote: +</I>>><i> +</I>>><i> So the mirror medias accordingly to all comments so far would be a simple: +</I>>><i> +</I>>><i> * core +</I>>><i> - enabled by default +</I>>><i> - mirrors must mirror this media to be listed as a mirror +</I>>><i> - only GPL stuff +</I>>><i> - must be selfcontained +</I>>><i> +</I>>><i> * nonfree +</I>>><i> - disabled by default, installer will ask to enable it if +</I>>><i> it detects hw that need driver/fw from here... +</I>>><i> - mirrors must mirror this media to be listed as a mirror +</I>>><i> - contains apps/drivers/firmware that are free to redistribute, +</I>>><i> but we dont have GPL source for +</I>>><i> - for example ati/nvidia drivers/firmware, Oracle Java, ... +</I>>><i> +</I>>><i> * tainted +</I>>><i> - disabled by default +</I>>><i> - mirrors are free to not mirror this media +</I>>><i> - stuff we think we can redistribute, but that may have some +</I>>><i> patent issues or other restrictions in oter countries. +</I>>><i> +</I>><i> +</I>><i> I can't agree with the "mirrors are free to not mirror this media", +</I>><i> three reasons: +</I>><i> 1) I don't see an easy and safe way for mirrors to exclude a media (a +</I>><i> directory + hdlist in media/media_info) in each distribution, +</I> +Thats easy, just use --exclude-from + +On my local mirror I exclude the debug stuff +so I use --exclude-from=excclude.lst + +# cat exclude.lst +i586/media/*debug* +i586/media/media_info/*debug* +x86_64/media/*debug* +x86_64/media/media_info/*debug* + +And thats all needed. +We can even provide this exclude file ourselves on the mirrors so we +know its correct and if we change the mirror layout, we update the file. + +><i> 2) I don't know how urpmi can manage this, all medias are described in +</I>><i> only one file, to detect something is missing +</I>><i> (media/media_info/media.cfg). +</I> +It already works. +For example if you only mirror x86_64, the media.cfg has references to +Main32 and Main32 Updates. but since the hdlists are symlinked to +../../../i586/media/... the hdlists and synthesis will be empty, +so no reference to any 32bit package gets into urpmi database. + +><i> 3) I tried to act as rules that a valid is a mirror containing +</I>><i> everything, to not have to deal with a lot of mirrors style. +</I>><i> +</I> +Well, +if te choice is between no mirror and a mirror without *tainted* +I'd choose the mirror without *tainted* + +-- +Thomas +</PRE> + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001490.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001500.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1491">[ date ]</a> + <a href="thread.html#1491">[ thread ]</a> + <a href="subject.html#1491">[ subject ]</a> + <a href="author.html#1491">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001492.html b/zarb-ml/mageia-dev/20101129/001492.html new file mode 100644 index 000000000..5143e4f49 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001492.html @@ -0,0 +1,442 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF36DE3.70505%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001496.html"> + <LINK REL="Next" HREF="001480.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF36DE3.70505%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Mon Nov 29 10:09:55 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001496.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001480.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1492">[ date ]</a> + <a href="thread.html#1492">[ thread ]</a> + <a href="subject.html#1492">[ subject ]</a> + <a href="author.html#1492">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael scherer a écrit : +><i> On Sat, Nov 27, 2010 at 08:00:17PM +0200, Thomas Backlund wrote: +</I>><i> +</I>>><i> Michael scherer skrev 27.11.2010 10:43: +</I>>><i> +</I>>>><i> On Fri, Nov 26, 2010 at 10:29:14PM +0200, Thomas Backlund wrote: +</I>>>><i> +</I>>><i> [...] +</I>>><i> +</I>>>>><i> Then we come to the "problematic" part: +</I>>>>><i> +</I>>>><i> This part look really too complex to me. +</I>>>><i> +</I>>>><i> +</I>>>>><i> ------ +</I>>>>><i> /x86_64/ +</I>>>>><i> /media/ +</I>>>>><i> /codecs/ (disabled by default) +</I>>>>><i> +</I>>>><i> so, ogg, webm, being codec, should go there or not ? +</I>>>><i> What about patents problem about something else than codec ? +</I>>>><i> ( freetype, image such as gif, DRM stuff ) +</I>>>><i> +</I>>>><i> +</I>>><i> Actually this is the "maybe_legal_greyzone" repo, +</I>>><i> but since flagging it as "codecs" would really make people +</I>>><i> react, I named it so for now... +</I>>><i> +</I>><i> Sorry to be so direct, but that's doesn't answer the question :/ +</I>><i> +</I>><i> +</I>>>>><i> /core/ (old main+contrib) +</I>>>>><i> /backports/ (disabled by default) +</I>>>>><i> /backports_testing/ (disabled by default) +</I>>>>><i> /release/ +</I>>>>><i> /testing/ (disabled by default) +</I>>>>><i> +</I>><i> Shall I suggest to name this one "updates_testing", for consistency ? +</I>><i> ( consistency with backport_testing, and because this explain what goes in +</I>><i> more clearly. This also look simpler ). +</I>><i> +</I>><i> +</I>>>>><i> /updates/ +</I>>>>><i> /extra/ (unmaintained, disabled by default) +</I>>>>><i> +</I>>>><i> If used by people, then why no one step to maintain anything ? +</I>>>><i> +</I>>><i> Yeah, thats the problem. +</I>>><i> +</I>><i> If this is the problem, how does it help to have people to maintain +</I>><i> the application ? +</I>><i> +</I>><i> So far, the only way that really work is +</I>><i> "someone take care or we shoot the do^W rpm". +</I>><i> So maybe we could just be more active with cleaning ? +</I>><i> +</I>><i> +</I>>><i> And reality shows we have a lot of packages assigned to nomaintainer@ ... +</I>>><i> +</I>>><i> +</I>>>>><i> /firmware/ (disabled by default) +</I>>>>><i> +</I>>>><i> Why separate firmware from non_free ? What does it bring ? +</I>>>><i> Since both of them are disabled by default, they can be simply merged. +</I>>>><i> +</I>>>><i> +</I>>><i> Well, this suggestion is partly based on the fact that we have users +</I>>><i> that want a firmware free install, wich this would satisfy... +</I>>><i> +</I>><i> I do not think this warrant a full media, maybe just a way to filter package. +</I>><i> +</I>><i> Using a media seems overkill to me, since this bring complexity in dialog box, from +</I>><i> easyurpmi to rpmdrake and installer, and since it bring complexity on mirror, on BS +</I>><i> and on our policy. +</I>><i> +</I>><i> Maybe we could find a way to tag them "firmware", like a rpmgroup. +</I>><i> +</I>Exactly. +The filtering will be more involved, but rpmdrake/urpmi need overhauling +anyway. +We just need to add an rpm group "system/firmware", and move firmware +packages from "system/kernel+hardware". +><i> The benefit is the complexity will only be on rpmdrake side, not on mirroring and BS +</I>><i> side. +</I>><i> +</I>><i> More ever, this would much more flexible ( ie, see the games option I propose later ). +</I>><i> +</I>><i> +</I>>><i> But yes, if we ignore those suggestions, we split the firmwares in +</I>>><i> GPL -> /core/ and the rest to /non-free/ +</I>>><i> +</I>>><i> +</I>>>>><i> /games/ (disabled by default) +</I>>>>><i> +</I>>>><i> That's a simplification that make no sense. +</I>>>><i> Not all games are big, not all big packages are games ( tetex, openoffice ). +</I>>>><i> +</I>>><i> It's not only a size question, its also a nice option for companies +</I>>><i> to not mirror games ("employees should work, not play...") +</I>>><i> +</I>><i> Such companies likely already have admins to prevent users from installing games. +</I>><i> Maybe we could add feature in rpmdrake for that ( like "do not show package +</I>><i> that match such conditions : group =~ games/, maintainer =~ nomaintainer@, requires =~ python ). +</I>><i> +</I>Excellent idea. I like the nomaintainer option :) +You can set some urpmi options by editing a config file. There has +already been suggestions to make this directly accessible in rpmdrake. +Once done, we just need to add more options. + +><i> The problem of private internal companies mirrors is really not our concern. +</I>><i> And their software policy, even if they may decide to apply it on a public mirror, +</I>><i> should not leak on our side. +</I>><i> +</I> +Right. No point in confusing issues. +>><i> And we have some contributors that already have stated that they +</I>>><i> plan to add all possible games so it will grow. +</I>>><i> and we all know games are the fastest growing /space demanding... +</I>>><i> +</I>><i> Well, so either that will cause a problem on our side, in which case this will +</I>><i> just be unhelpful on our primary mirrors, or it will only cause issues on some mirrors, +</I>><i> and in this case, there is lots of other thing that can take space that we do not +</I>><i> take in account : +</I>><i> - debug +</I>><i> - source code ( except that a GPL requirement ) +</I>><i> - adding another arch ( like arm/mips ) +</I>><i> - adding more iso ( something that is asked each time, like 64 bits one, etc ) +</I>><i> +</I>><i> So if we decide "mirrors will not handle the load, so we need to split games", then we +</I>><i> should also say "mirrors will not handle the load, so we need to do less iso/offer to not +</I>><i> mirror debug/offer to not mirror some architecture", and we end with a non consistent +</I>><i> network of mirror, with lots of complexity on our side to handle the possible choice +</I>><i> made by mirrors. I am not sure that users +</I>><i> will truly benefit from this. And I am sure that we will not benefit from the complexity. +</I>><i> +</I>><i> If the space is a issue ( and I think that's one of the main one ), then we should decide +</I>><i> based on metrics. Ie, we plan to have no more than X% growth in mirror size for 1 year. +</I>><i> If we hit some soft limit, then we investigate and decide ( ie, stop adding big backport, +</I>><i> stop adding new package, etc ). +</I>><i> +</I>><i> And decide the metrics based on mirrors input, and based on packagers input. +</I>><i> But so far, apart from Olivier and Wolfgang, we do not have much metrics and +</I>><i> requirements :/ +</I>><i> +</I>><i> +</I>>>>><i> /non-free/ (disabled by default) +</I>>>>><i> /debug_*/ (disabled by default) +</I>>>>><i> +</I>>>><i> +</I>>>><i> And what are the relation of requirements ? +</I>>>><i> Ie, what can requires non_free, codecs, games, etc ? +</I>>>><i> +</I>>>><i> +</I>>><i> IMHO /core/ should be selfcontained. +</I>>><i> We are promoting open source after all. +</I>>><i> +</I>><i> Yes, but what about the others ? +</I>><i> Ie, can a game requires a codec or not ? a package in extra ? +</I>><i> If we remove a package from extra, do we remove everything +</I>><i> that requires it ? +</I>><i> +</I>><i> +</I>>>><i> And what about something that can goes in both media, ie a non_free +</I>>>><i> game goes where ? A unmaintained codecs goes where ? +</I>>>><i> +</I>>><i> Yeah, to be precise, that would need a games_non-free +</I>>><i> +</I>><i> another media ? Really, I think most users are already lost with the +</I>><i> current media selection. +</I>><i> For core, we have 15/20 medias ( src + debug + binary ( 1 or 2 ) * update/release/testing/backport/ +</I>><i> backport testing ). Each media we add at the level of core will therefore add 15 to 20 medias too. +</I>><i> So firmware, game, extras, codecs, non_free, that would make the total around 80 to 90 medias for a single +</I>><i> arch ( I assume that firmware may not have debug_* ) +</I>><i> +</I>><i> While it can be partially solved with a better interface for selecting media, +</I>><i> we cannot do miracles if there is too much things :/ +</I>><i> +</I>><i> So let's try to think how we can reduce the number of media. +</I>><i> +</I>><i> We have 2 kind of issue we try to solve at mirror level : +</I>><i> - the concern of mirror admins +</I>><i> - the concern of users. +</I>><i> with impact on BS and packagers +</I>><i> +</I>><i> Mirror admins are concerned by : +</I>><i> - size and growth ( see Wobo mail in the past thread ) +</I>><i> - content ( or at least, we think ) +</I>><i> +</I>><i> Content part is mainly legal matter, but I didn't heard any admin +</I>><i> telling "we can't do that", so that's my interpretation. The concern is +</I>><i> mainly around DCMA and EUCD, even if lesser know laws also exist around +</I>><i> the world ( like the Paragraph 202C of German law, who ban "hacking tools" ). +</I>><i> For DMCA, there is some protection for them : +</I>><i> <A HREF="http://www.benedict.com/Digital/Internet/DMCA/DMCA-SafeHarbor.aspx">http://www.benedict.com/Digital/Internet/DMCA/DMCA-SafeHarbor.aspx</A> . +</I>><i> For EUCD and the rest, I do not know. +</I>><i> +</I>><i> +</I>><i> Users are concerned with a wide range of issues, some contradictory : +</I>><i> - some want newer stuff, some don't +</I>><i> - some want stable stuff, some do not care as much +</I>><i> - some want non_free, some don't want it +</I>><i> - some want firmware, some don't +</I>><i> - etc +</I>><i> +</I>><i> Yet, the users concern mainly evolve around 2 things : +</I>><i> - package availiability +</I>><i> - package filtering, based on packages content +</I>><i> +</I>><i> The first part is already solved by the subdivision ( release, etc ). We +</I>><i> need to split them for build reason. So we can't really avoid adding +</I>><i> medias on this part. +</I>><i> +</I>><i> The second part is more tricky. And in fact, I think we can avoid creating media +</I>><i> for this. Ie, do not let the concern of filtering appearing on +</I>><i> the BS and mirrors, and push this on endusers system. +</I>><i> Some people do not want firmware on their system, they do not really care about +</I>><i> the firmware being in a separate directory on mirrors, as long as they can +</I>><i> disable them easily from the list of package they can install ( at +</I>><i> perl-urpm level, IMHO ). +</I>><i> +</I>><i> Same goes for non_free, or for nomaintained software. Or even games. +</I>><i> +</I>><i> So if we push the users issues on endusers system, we only have to manage the +</I>><i> mirror admins issue on mirror. +</I>><i> +</I> +Exactly. +><i> And so here is a proposal that start by the size issue : +</I>><i> +</I>><i> - discuss with mirror admin, decide on a size that everybody would agree to mirror +</I>><i> for core/ for the next release, or the 2 next one. Ie, every year or every 6 months, +</I>><i> we do a survey of our mirrors, to see if everything goes well for them. +</I>><i> - discuss also of the growth of core in term of size +</I>><i> - decide on a limit size +</I>><i> - if anything goes off limit for mirror, add a overflow/ to hold the packages +</I>><i> that will not be mirrored by everybody. Overflow will be treated like core, in all points. +</I>><i> Only difference is that mirroring is optional ( but strongly encouraged ) +</I>><i> - put everything in core, except what goes to overflow. +</I>><i> - let users filter on their system, with something urpmi side ( I suggest a filtering +</I>><i> when we do urpmi.update, but the exact details of how to do it are not relevent now ). +</I>><i> +</I>><i> Overflow will be filled with packages that : +</I>><i> 1) are not required by anything else ( thus games data would likely fit, +</I>><i> but not only ) +</I>><i> 2) have triggered the limit of size +</I>><i> +</I>><i> After the limit of core size is raised ( ie after all mirror have agreed ),we can readd packages +</I>><i> from overflow to core, based on +</I>><i> criteria not defined yet ( first come first serve, try to make most useful first ? +</I>><i> or some wild guesstimate based on some mirrors stats ? ). But being in core or +</I>><i> overflow should not change anything for both enduser and packagers. This is +</I>><i> a mirror only concern, and so should be kept there only. +</I>><i> And this should avoid discussion about the location of packages by packagers. +</I>><i> +</I>><i> This mean that both core and overflow should be by default on users system. +</I>><i> +</I>Agreed. +><i> ( and I would not be against a better name, but I didn't found one ) +</I>><i> +</I>I like extra, which would fit nicely with the approach I'm about to suggest. + +I would take a similar but somewhat different approach, which would +probably have at least as good results. +First, decide what is *essential* to a fully functioning desktop or +server or development system. That goes into core. +Then decide what would be *very useful* in a typical such system. Add +that to core. +Of course, only the free packages. Those not free would remain in non-free. + +Core should then have the various kernels, the usual Linux utilities and +development tools, the drak* and associated utilities. Various +pilotes. The compete desktops, such as Gnome, KDE, LXDE, etc. And +certain common applications, such as LibreOffice, Firefox. +This leaves a lot of other packages, to go into extra. (or overflow, if +you prefer.) +Games would generally be in extra. Or non-free. (There may be a few +small exceptions.) + +This leaves many applications now in main, as well as virtually +everything now in contrib, which would be in extra. +So core would be (probably much) smaller than main, and thus extra +bigger than contrib. +And core would be just that : the core of Mageia. + +Besides any advantage for space-limited mirrors which may exclude extra, +we could collectively focus on ensuring first that everything in core +works, to help ensure that user's systems would always be functional. +Being reliable won't hurt our reputation. +><i> +</I>><i> In order to reduce number of media, another question is : +</I>><i> - should non_free have it own media ? +</I>><i> +</I>><i> Having them in core would simplify the BS, the upload and the mirroring. +</I>><i> +</I>><i> Having it separated would be better from various points of view ( political, +</I>><i> communication, etc ). Maybe some people will refuse to help us if we don't, +</I>><i> maybe there is some further restriction on some non-free software leading us +</I>><i> to create another media whatever we do, I do not know. +</I>><i> To me, as long as we can filter on user side, it would be ok. +</I>><i> +</I>><i> I cannot really tell what I prefer for that :/ +</I>><i> +</I>I think it is better to keep non-free. It makes it very obvious to +everyone, and avoids the down sides you mention. +We still avoid adding 3 sets of repositories :) +><i> +</I>><i> So the only important mirror issue left to solve is the greyzone area. +</I>><i> And well, that's quite complex. +</I>><i> +</I>><i> So we can either : +</I>><i> +</I>><i> 1) decide to not care ( ie everything in core ) +</I>><i> 2) decide to not offer them at all ( aka offload to PLF ) +</I>><i> 3) decide to add a media ( aka the "codecs" media ) +</I>><i> +</I>><i> 1 is the simplest. But maybe not really a good idea. +</I>><i> +</I>><i> If we care, then what indeed should be done is another media, and let admins +</I>><i> choose to mirrors it or not. I would even propose to revise the idea of +</I>><i> separation every year, because if all mirrors have the +</I>><i> 2 medias, no need to split in reality ( but I doubt it will happen, but +</I>><i> at least, this would show that we try to revise our fondation on a regular +</I>><i> basis ). And at least, we should revise the packages present in such medias. +</I>><i> If there is some packages that can be moved to core, +</I>><i> then they should. +</I>><i> +</I>><i> We could also simplify a bit the BS by placing non-free packages there +</I>><i> ( instead of either having a non_free media, or the non_free pacakges in core ). +</I>><i> It would sadden me a little to blur the line between "free with patents problems" +</I>><i> from "non free", but my PLF experience showed that most people do not care, and that +</I>><i> it requires more than a media separation. +</I>><i> +</I>><i> So, in the end, we would have : +</I>><i> +</I>><i> core/ +</I>><i> release +</I>><i> updates +</I>><i> updates_testing +</I>><i> +</I>improved name. +><i> backports +</I>><i> backports_testing +</I>><i> +</I>><i> "overflow"/<- big packages, just for mirroring issues +</I>><i> +</I> +Which I would prefer to call "extra". (Note that I suggest above a +somewhat different contents, which would probably make it larger, and +core smaller.) +Thus a mirror dropping it would save more space. + +><i> restricted/<- with non_free, firmware, "codecs" +</I>><i> +</I> +It seems to me that totally free (of patents, etc) codecs would be +better in core. +But the name allows containing packages that are nominally free, which +is excellent. +><i> with the 5 directories under them, and with src, debug, binary. +</I>><i> Imho, 3 upper medias is the simplest we can have ( besides debug/src, that +</I>><i> I would place also on the same level than the binaries, but my +</I>><i> mail is already long enough :/ ) +</I>><i> +</I> +Long but very useful :) +To save additional space, maybe minimal mirrors could drop ISOs as well. +And maybe we could have other minimal mirrors with only all current ISOs. + +In any case, at this point the important to decide what repositories to +have. +Essentially I agree with your proposals. +>><i> For codecs either a extra_codecs or simply drop after a grace period. +</I>>><i> but I guess codecs are important to people, so hopefully they wont +</I>>><i> get orphaned... +</I>>><i> +</I>><i> Unfortunately, there is not always a relation between "being important +</I>><i> to users" and "someone want to take the burden of maintaining it" :/ +</I>><i> For example, something like etherpad would be nice for users, +</I>><i> yet no one will take time to maintain it. +</I> +The proposed Mageia-app-db will hopefully help Mageia respond better to +user's needs/desires. + +my 2 cents :) + +- André +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001496.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001480.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1492">[ date ]</a> + <a href="thread.html#1492">[ thread ]</a> + <a href="subject.html#1492">[ subject ]</a> + <a href="author.html#1492">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001493.html b/zarb-ml/mageia-dev/20101129/001493.html new file mode 100644 index 000000000..f922fa889 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001493.html @@ -0,0 +1,192 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF3779C.5050403%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001500.html"> + <LINK REL="Next" HREF="001494.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF3779C.5050403%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Mon Nov 29 10:51:24 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001500.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001494.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1493">[ date ]</a> + <a href="thread.html#1493">[ thread ]</a> + <a href="subject.html#1493">[ subject ]</a> + <a href="author.html#1493">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael scherer a écrit : +><i> On Sat, Nov 27, 2010 at 08:23:59PM +0200, Thomas Backlund wrote: +</I>><i> +</I>>><i> Jerome Quelin skrev 27.11.2010 19:11: +</I>>><i> +</I>>>><i> On 10/11/27 17:59 +0100, Maarten Vanraes wrote: +</I>>>><i> +</I>>>><i> what are the rules to move a package from extra to core, and vice-versa? +</I>>>><i> who can do it? will it be done automatically? will this imply a rebuild +</I>>>><i> for the package? +</I>>>><i> +</I>>><i> If a maintainer picks up maintainership of a package in /extra/ it will +</I>>><i> be rebuilt and moved to /core/ asap. +</I>>><i> +</I>>><i> if a package in /core/ ends up nomaintainer@, then after a "grace +</I>>><i> period" (1-3 months ?) it will be moved to /extra/. +</I>>><i> and sometime before RC1 or so, any momaintainer@ package in /core/ +</I>>><i> will get moved to /extra/ as for a release the /core/ should only +</I>>><i> contain maintained packages. +</I>>><i> +</I>><i> But isn't it in contradiction with the fact that release should not be changed ? +</I>><i> +</I>><i> IE, a package could be in core for one release, and extras in another. +</I>><i> +</I>><i> What happen to such shrodingerian packages ? +</I>><i> What happen if this break the self containement ? +</I>><i> And finally, isn't it redoing contribs/main , leading in the future to the same +</I>><i> problem we tried to avoid ? +</I>><i> +</I> +It's simply not workable to base a package's repository on whether it is +currently maintained or not. +It is much better to classify it on whether it *should* be maintained, +in order to have a fully functional user's system. +That is, it is in core because it is *core* to a typical fully +functional desktop or server or developer's system. Or very useful to +such a system. +So if such a package is not being properly maintained, there is a +collective focus to make sure that it is maintained, so that user's +systems remain functional. + +Extra should be just that. Packages that are extra to a fully +functional core Mageia system. + +It is inevitable that most packages, whatever their importance, will be +unmaintained - or at least without an official maintainer - from time to +time. +What we don't want to happen is a repository yoyo - where a package +bounces from core to main and back - just on the basis of its current +maintenance status. + +And a package should *never* change repositories between releases. +><i> +</I>><i> +</I>>>><i> what are the dependency rules? can a core package depend on an extra +</I>>>><i> package? or with a buildrequires? +</I>>>><i> +</I>>><i> No. +</I>>><i> If you need to build against a package in /extra/, either pick up +</I>>><i> the maintainership of it, or try to get someone other to maintain +</I>>><i> it. +</I>>><i> then it can get into /core/ +</I>>><i> +</I> +Seems like a lot of wasted effort - which could be better applied simply +maintaining core packages. +><i> And so, if no one step, wouldn't it be like current mdv, where people will say +</I>><i> they maintain the package just because someone has to do the job ? +</I>><i> +</I> +Note that Mandriva is currently overhauling their system - to remove +much non-core packages from main. +><i> +</I>><i> +</I>>>><i> and, more importantly: what is the advantage? that is, what does that +</I>>>><i> bring you, except more admin? +</I>>>><i> +</I>>>><i> +</I>>><i> QA! +</I>>><i> and enduser satisfaction. +</I>>><i> +</I>>><i> Just take a look on many bugreports in MDV Bugzilla. +</I>>><i> If the report is against a nomaintainer@ package, currently Triage +</I>>><i> pretty much only can state "thanks for your report, but since it has +</I>>><i> no maintainer, nothing will probably happend" wich is not good answer +</I>>><i> for a person that have taken the time to report a bug. +</I>>><i> +</I>><i> Then why don't we either : +</I>><i> - decide that non maintened package must be taken care by trainee, as +</I>><i> part of the training +</I>><i> - decide to clean them. +</I>><i> +</I> +Exactly. +>><i> By having the /extra/ disabled by default, and a popup notifying the +</I>>><i> user if he enables it that the packages are "unmaintained" he knows +</I>>><i> he's "on his own" +</I>>><i> +</I> +That's ridiculous. We should be in the cooperative spirit of the GPL, +instead of saying "too bad, you can't depend on Mageia." +><i> That's already what the GPL say, basically :) +</I>><i> ( you have no garantee of anything ). +</I>><i> +</I> +But no garantee doesn't mean no help. +><i> Yet, I fail to see what benefit it does really bring to users. Most of them +</I>><i> will enable the media ( because some people enable everything ), will forget +</I>><i> the message ( because we always forget popup, thanks +</I>><i> to endless abuse of such popup ), +</I>><i> and the only benefit is that we could tell "we told you". Not really satisfying, +</I>><i> and if I was a user, it would not really please me, nor inspire confidence. +</I>><i> +</I>><i> We could avoid adding a media by merging this media with core, +</I>><i> and show the popup when a user install a package without maintainer, +</I>><i> telling either "beware, this package is currently marked as not maintained, and may +</I>><i> be buggy. We will try to do what we can to help in this case, but no one is officialy in charge" +</I>><i> or "we are seeking help on taking care of this package, if you use it often, please +</I>><i> register on $URL" +</I>><i> +</I>><i> +</I>Not a bad idea. Why not both messages ? +Really better than an option to exclude seeing officially non-maintained +packages. +Some packages on my system work perfectly well, but haven't been +"maintained" for several years. + +I would still keep a separate core and extra, where core is core, and +extra is extra. +(As I described above and in more detail in previous posts to this thread.) + +- André + +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001500.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001494.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1493">[ date ]</a> + <a href="thread.html#1493">[ thread ]</a> + <a href="subject.html#1493">[ subject ]</a> + <a href="author.html#1493">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001494.html b/zarb-ml/mageia-dev/20101129/001494.html new file mode 100644 index 000000000..f0b47bf64 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001494.html @@ -0,0 +1,87 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF37C45.6060201%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001493.html"> + <LINK REL="Next" HREF="001495.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF37C45.6060201%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Mon Nov 29 11:11:17 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001493.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001495.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1494">[ date ]</a> + <a href="thread.html#1494">[ thread ]</a> + <a href="subject.html#1494">[ subject ]</a> + <a href="author.html#1494">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael scherer a écrit : +><i> On Sat, Nov 27, 2010 at 11:16:57PM +0100, Maarten Vanraes wrote: +</I>><i> +</I>... +>><i> is there a way to get rpm usage stats from those unmaintained packages. +</I>>><i> +</I>><i> No. We can only get download stats from mirrors. While it may be biased toward +</I>><i> some geographical preference ( ie, I doubt many people download locale-zh +</I>><i> from distrib-coffee ), it can give at least some ideas. Nothing precise, but +</I>><i> still better than random. +</I>><i> +</I> +If the package in question is on an ISO, we can only speculate if it was +installed from the ISO. +So we would have individual downloads + possibly any/all ISOs (one or +more times). +><i> +</I>>><i> they really do so, it's kind of their own fault. i don't think the majority +</I>>><i> does that. the majority leaves it at default. +</I>>><i> +</I>><i> And so the majority will say "$distro is bad because there is not enough software". +</I>><i> +</I> +Exactly. So sense hiding officially non-maintained packages. Many work +perfectly well. And for those that don't, resulting bug reports could +result in them being fixed. + +- André +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001493.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001495.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1494">[ date ]</a> + <a href="thread.html#1494">[ thread ]</a> + <a href="subject.html#1494">[ subject ]</a> + <a href="author.html#1494">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001495.html b/zarb-ml/mageia-dev/20101129/001495.html new file mode 100644 index 000000000..7a8fee24c --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001495.html @@ -0,0 +1,147 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF3928E.50708%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001494.html"> + <LINK REL="Next" HREF="001497.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF3928E.50708%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Mon Nov 29 12:46:22 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001494.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001497.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1495">[ date ]</a> + <a href="thread.html#1495">[ thread ]</a> + <a href="subject.html#1495">[ subject ]</a> + <a href="author.html#1495">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Thomas Backlund a écrit : +><i> +</I>><i> ... +</I>><i> +</I>><i> One thing hit me now... +</I>><i> I've only been thinking of current cooker and all of the old stuff +</I>><i> there... +</I>><i> +</I>><i> But since we are going to have to import/rebuild every package we +</I>><i> need, it gets real easy... We just dont import any unmaintained stuff. +</I> +Note that just because a package doesn't have an official maintainer, or +hasn't been changed for several years, doesn't mean that it is +non-functional. So packages should be tested before being eliminated. +><i> +</I>><i> That way we get a clean mirror start for Mageia. +</I>><i> +</I>><i> And if someone import a package, it makes him the maintainer. +</I>><i> +</I>><i> Then if a package loses it maintainer, we need a policy like "if its +</I>><i> not maintained for X months, we drop it from the mirrors... +</I> +I have some very nice small programs that work very well on my system, +that haven't been changed/maintained for years. +It might be better to use unmaintained packages as a training ground for +new packagers, as suggested elsewhere in this thread. +><i> +</I>><i> So the mirror medias accordingly to all comments so far would be a +</I>><i> simple: +</I>><i> +</I>><i> * core +</I>><i> - enabled by default +</I>><i> - mirrors must mirror this media to be listed as a mirror +</I>><i> - only GPL stuff +</I>><i> - must be selfcontained +</I> +As already commented in previous posts, I would rather see this split +into 2 parts : +1) core = really core (or very useful) to a fully functional desktop or +server or developer system. +Examples include packages for the kernel, usual Linux utilities and +development tools, drivers, drak* and associated tools, complete desktop +environments (such as Gnome, KDE, LXDE), and common applications such as +LibreOffice (successor to Go-Openoffice) and Firefox. + + This would essentially be a subset (most) of Mandriva main, with +possibly some from Mandriva contrib. These packages may not depend on +packages in extra. + Every effort must be collectively made to ensure that packages in this +group are maintained. + +and + +2) extra = supplementary packages which, if they break, will not affect +core. + This is essentially all (or least all maintained) of Mandriva contrib +and much of Mandriva main. +Typical examples include calendar printing programs, poedit (for +translators), and games. + +Extra would probably be much larger than main. (After eliminating +non-functional non-maintained packages.) +><i> +</I>><i> * nonfree +</I>><i> - disabled by default, installer will ask to enable it if +</I>><i> it detects hw that need driver/fw from here... +</I>><i> - mirrors must mirror this media to be listed as a mirror +</I>><i> - contains apps/drivers/firmware that are free to redistribute, +</I>><i> but we dont have GPL source for +</I>><i> - for example ati/nvidia drivers/firmware, Oracle Java, ... +</I>><i> +</I>><i> * tainted +</I>><i> - disabled by default +</I>><i> - mirrors are free to not mirror this media +</I>><i> - stuff we think we can redistribute, but that may have some +</I>><i> patent issues or other restrictions in oter countries. +</I> +I would rather call it "restricted". For most potential users, its +content wouldn't be seen as "tainted". + +Otherwise, it seems a good breakdown. +Note +><i> +</I>><i> -- +</I>><i> Thomas +</I> +- André + +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001494.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001497.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1495">[ date ]</a> + <a href="thread.html#1495">[ thread ]</a> + <a href="subject.html#1495">[ subject ]</a> + <a href="author.html#1495">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001496.html b/zarb-ml/mageia-dev/20101129/001496.html new file mode 100644 index 000000000..7ce2bea57 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001496.html @@ -0,0 +1,72 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291241.09353.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001489.html"> + <LINK REL="Next" HREF="001492.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291241.09353.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 12:41:09 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001489.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001492.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1496">[ date ]</a> + <a href="thread.html#1496">[ thread ]</a> + <a href="subject.html#1496">[ subject ]</a> + <a href="author.html#1496">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le lundi 29 novembre 2010 04:32:07, Olivier Thauvin a écrit : +><i> If you're maintaining a mirror you should first take care about the +</I>><i> ressources need by each distro you host, and small mirror won't probably +</I>><i> host mageia. +</I>><i> There enough big mirrors around the world able to host us to not +</I>><i> encourage small one to mirror us with bad practices, IMHO. +</I>><i> +</I> +This is insightful. I was the one to propose a separate games media to allow mirrors to exclude them (for size reasons), but I think that we could first try to avoid to split media into "games" or "overflow" secondary media. + +That is quite a simplification, I think we should postpone any size-related splitting. + +Regards + +Samuel + +</PRE> + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001489.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001492.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1496">[ date ]</a> + <a href="thread.html#1496">[ thread ]</a> + <a href="subject.html#1496">[ subject ]</a> + <a href="author.html#1496">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001497.html b/zarb-ml/mageia-dev/20101129/001497.html new file mode 100644 index 000000000..9db444da6 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001497.html @@ -0,0 +1,108 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291314.08739.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001495.html"> + <LINK REL="Next" HREF="001503.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291314.08739.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 13:14:08 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001495.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001503.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1497">[ date ]</a> + <a href="thread.html#1497">[ thread ]</a> + <a href="subject.html#1497">[ subject ]</a> + <a href="author.html#1497">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le lundi 29 novembre 2010 12:46:22, andre999 a écrit : +><i> As already commented in previous posts, I would rather see this split +</I>><i> into 2 parts : +</I>><i> 1) core = really core (or very useful) to a fully functional desktop or +</I>><i> server or developer system. +</I>><i> Examples include packages for the kernel, usual Linux utilities and +</I>><i> development tools, drivers, drak* and associated tools, complete desktop +</I>><i> environments (such as Gnome, KDE, LXDE), and common applications such as +</I>><i> LibreOffice (successor to Go-Openoffice) and Firefox. +</I>><i> +</I>><i> This would essentially be a subset (most) of Mandriva main, with +</I>><i> possibly some from Mandriva contrib. These packages may not depend on +</I>><i> packages in extra. +</I>><i> Every effort must be collectively made to ensure that packages in this +</I>><i> group are maintained. +</I>><i> +</I>><i> and +</I>><i> +</I>><i> 2) extra = supplementary packages which, if they break, will not affect +</I>><i> core. +</I>><i> This is essentially all (or least all maintained) of Mandriva contrib +</I>><i> and much of Mandriva main. +</I>><i> Typical examples include calendar printing programs, poedit (for +</I>><i> translators), and games. +</I>><i> +</I>><i> Extra would probably be much larger than main. (After eliminating +</I>><i> non-functional non-maintained packages.) +</I> +I agree with andre999 on this point : the "everything in core" approach makes no distinction between packages which I can trust (for servers for example) and packages which I can't rely on. + +It was said early that you just have to look at whether the package has a maintainer or not to make a distinction, but this is not sufficient. A maintainer can be very active in cauldron but not care about maintaining for stable releases. A package can have no maintainer but be actively supported in practice (by everybody in cauldron, by security team in stable releases). + +The current main vs contrib approach in mandriva is very sensible. It has some (minor, to me) drawbacks, but when I install packages from main I *know* there will be security updates, bugfix updates, and a QA process that packages in contrib don't have. Do we plan to have no QA process at all in Mageia ? If we plan to have such processes, does the merge between core and extra make is efficient ? I guess we don't plan to have all packages (even maintained ones) equally supported with a full QA process (doesn't seem realistic) ? + +If we define collectively what "core" contains, then we can ensure that every package there has : +- a maintainer who takes care of it in cauldron +- a maintainer who takes care of security and bugfix updates in stable release (maybe the same person, maybe not) +- (when doable) a maintainer who takes care of backports for this package (maybe the same person, maybe not) +- a QA team which will review changes on stable releases for these packages + +Packages in core get the "QA approved" stamp whereas packages in extra get none. + +Therefore I'm against the merge of core and extra. + +Regards + +Samuel Verschelde + +</PRE> + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001495.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001503.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1497">[ date ]</a> + <a href="thread.html#1497">[ thread ]</a> + <a href="subject.html#1497">[ subject ]</a> + <a href="author.html#1497">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001498.html b/zarb-ml/mageia-dev/20101129/001498.html new file mode 100644 index 000000000..e996b9b0e --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001498.html @@ -0,0 +1,99 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291319.26245.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001526.html"> + <LINK REL="Next" HREF="001499.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291319.26245.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 13:19:26 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001526.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001499.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1498">[ date ]</a> + <a href="thread.html#1498">[ thread ]</a> + <a href="subject.html#1498">[ subject ]</a> + <a href="author.html#1498">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le samedi 27 novembre 2010 17:20:34, Jerome Quelin a écrit : +><i> +</I>><i> On 10/11/26 22:29 +0200, Thomas Backlund wrote: +</I>><i> > The "core" should be only maintained free/libre stuff so it's easy +</I>><i> > to build a free/libre iso +</I>><i> > +</I>><i> > "extra" is for those packages that no-one really maintain, but is +</I>><i> > still used by someone +</I>><i> +</I>><i> i'm not sure "extra" is needed. either it compiles, and then it's +</I>><i> shipped. or it doesn't, and then it's dropped. +</I>><i> +</I> +Isn't that a cooker's point of view, without any concern for stable release maintenance ? + +- "it compiles" doesn't mean it works or has no security issue +- it does not mean there is someone which will maintain it for stable releases (security and bugfix updates). + +Regards + +Samuel Verschelde + +</PRE> + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001526.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001499.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1498">[ date ]</a> + <a href="thread.html#1498">[ thread ]</a> + <a href="subject.html#1498">[ subject ]</a> + <a href="author.html#1498">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001499.html b/zarb-ml/mageia-dev/20101129/001499.html new file mode 100644 index 000000000..410c7d2fc --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001499.html @@ -0,0 +1,84 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291321.03937.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001498.html"> + <LINK REL="Next" HREF="001501.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291321.03937.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 13:21:03 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001498.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001501.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1499">[ date ]</a> + <a href="thread.html#1499">[ thread ]</a> + <a href="subject.html#1499">[ subject ]</a> + <a href="author.html#1499">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le vendredi 26 novembre 2010 21:29:14, Thomas Backlund a écrit : +><i> /backports_testing/ (disabled by default) +</I> +I've been waiting for this media for a long time, thumbs up ! + +Samuel + +</PRE> + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001498.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001501.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1499">[ date ]</a> + <a href="thread.html#1499">[ thread ]</a> + <a href="subject.html#1499">[ subject ]</a> + <a href="author.html#1499">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001500.html b/zarb-ml/mageia-dev/20101129/001500.html new file mode 100644 index 000000000..a78a25366 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001500.html @@ -0,0 +1,99 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129132838.GZ7479%40virgo.home.nanardon.zarb.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001491.html"> + <LINK REL="Next" HREF="001493.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Olivier Thauvin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129132838.GZ7479%40virgo.home.nanardon.zarb.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">nanardon at nanardon.zarb.org + </A><BR> + <I>Mon Nov 29 14:28:38 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001491.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001493.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1500">[ date ]</a> + <a href="thread.html#1500">[ thread ]</a> + <a href="subject.html#1500">[ subject ]</a> + <a href="author.html#1500">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>* Thomas Backlund (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">tmb at iki.fi</A>) wrote: +><i> Olivier Thauvin skrev 29.11.2010 03:06: +</I>>><i> * Thomas Backlund (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">tmb at iki.fi</A>) wrote: +</I>>><i> I can't agree with the "mirrors are free to not mirror this media", +</I>>><i> three reasons: +</I>>><i> 1) I don't see an easy and safe way for mirrors to exclude a media (a +</I>>><i> directory + hdlist in media/media_info) in each distribution, +</I>><i> +</I>><i> Thats easy, just use --exclude-from +</I>><i> +</I>><i> On my local mirror I exclude the debug stuff +</I>><i> so I use --exclude-from=excclude.lst +</I>><i> +</I>><i> # cat exclude.lst +</I>><i> i586/media/*debug* +</I>><i> i586/media/media_info/*debug* +</I>><i> x86_64/media/*debug* +</I>><i> x86_64/media/media_info/*debug* +</I>><i> +</I>><i> And thats all needed. +</I>><i> We can even provide this exclude file ourselves on the mirrors so we +</I>><i> know its correct and if we change the mirror layout, we update the file. +</I> +Completly not realist on mirror admin side. + +You really have to remember that first mirror admin job is not maintains +mirrors. They have often hundred of users on their back waiting for +fixes. + +When such will go wrong, nobody will be able to check and fix. + +-- + +Olivier Thauvin +CNRS - LATMOS +♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20101129/78af77cf/attachment.asc> +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001491.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001493.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1500">[ date ]</a> + <a href="thread.html#1500">[ thread ]</a> + <a href="subject.html#1500">[ subject ]</a> + <a href="author.html#1500">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001501.html b/zarb-ml/mageia-dev/20101129/001501.html new file mode 100644 index 000000000..fd4a78198 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001501.html @@ -0,0 +1,87 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129135125.GG21938%40mars-attacks.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001499.html"> + <LINK REL="Next" HREF="001502.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>nicolas vigier</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129135125.GG21938%40mars-attacks.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">boklm at mars-attacks.org + </A><BR> + <I>Mon Nov 29 14:51:25 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001499.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001502.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1501">[ date ]</a> + <a href="thread.html#1501">[ thread ]</a> + <a href="subject.html#1501">[ subject ]</a> + <a href="author.html#1501">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Sat, 27 Nov 2010, Thomas Backlund wrote: + +><i> +</I>><i> nope, the same layout: +</I>><i> backports (disabled by default) +</I>><i> backports_testing (disabled by default) +</I>><i> release +</I>><i> testing (disabled by default) +</I>><i> updates +</I> +Maybe testing can be renamed to updates_testing to make it more clear. + +</PRE> + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001499.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001502.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1501">[ date ]</a> + <a href="thread.html#1501">[ thread ]</a> + <a href="subject.html#1501">[ subject ]</a> + <a href="author.html#1501">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001502.html b/zarb-ml/mageia-dev/20101129/001502.html new file mode 100644 index 000000000..4c0651c56 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001502.html @@ -0,0 +1,107 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129135616.GH21938%40mars-attacks.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001501.html"> + <LINK REL="Next" HREF="001523.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>nicolas vigier</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129135616.GH21938%40mars-attacks.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">boklm at mars-attacks.org + </A><BR> + <I>Mon Nov 29 14:56:16 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001501.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001523.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1502">[ date ]</a> + <a href="thread.html#1502">[ thread ]</a> + <a href="subject.html#1502">[ subject ]</a> + <a href="author.html#1502">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Sat, 27 Nov 2010, Thomas Backlund wrote: + +><i> Wolfgang Bornath skrev 27.11.2010 10:03: +</I>>><i> 2010/11/27 Ahmad Samir<<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">ahmadsamir3891 at gmail.com</A>>: +</I>>>><i> +</I>>>><i> IMHO, the mirrorlist in its current status should be dropped +</I>>>><i> altogether... it's only good if the user has good mirrors near where +</I>>>><i> he lives, otherwise it just fails miserably. The whole point of using +</I>>>><i> a mirrorlist was that "urpmi will switch to another mirror if the +</I>>>><i> currently used one fails / can't be reached", that switch doesn't +</I>>>><i> happen, ("md5sum mismatch" rings a bell?). +</I>>><i> +</I>>><i> Although I am a friend of SmartUrpmi and EasyUrpmi I do understand the +</I>>><i> easy way the mirrorlist system provides, especially for new users. The +</I>>><i> failure of this system due to failing mirrors was already discussed at +</I>>><i> Mandriva and there is a bug in MDv bugzilla about it - still open. +</I>>><i> +</I>>><i> But even if this bug could be fixed, the option for mirror maintainers +</I>>><i> to exclude parts of the official mirror structure puts the mirrorlist +</I>>><i> system in jeopardy, unless we have 2 mirrorlists, one with and one +</I>>><i> without "problematic" software and let the user select one or the +</I>>><i> other before he sets up his media. +</I>>><i> +</I>><i> +</I>><i> This is actually an option I thought of... +</I>><i> +</I>><i> Providing two mirror list, one list with "free" mirrors and one with "full" +</I>><i> mirrors. +</I> +Or one list, but listing all medias individually. + +</PRE> + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001501.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001523.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1502">[ date ]</a> + <a href="thread.html#1502">[ thread ]</a> + <a href="subject.html#1502">[ subject ]</a> + <a href="author.html#1502">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001503.html b/zarb-ml/mageia-dev/20101129/001503.html new file mode 100644 index 000000000..dff155cea --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001503.html @@ -0,0 +1,154 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1291038980.8266.102.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001497.html"> + <LINK REL="Next" HREF="001506.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1291038980.8266.102.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">misc at zarb.org + </A><BR> + <I>Mon Nov 29 14:56:20 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001497.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001506.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1503">[ date ]</a> + <a href="thread.html#1503">[ thread ]</a> + <a href="subject.html#1503">[ subject ]</a> + <a href="author.html#1503">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 29 novembre 2010 à 13:14 +0100, Samuel Verschelde a écrit : +><i> +</I>><i> It was said early that you just have to look at whether the package +</I>><i> has a maintainer or not to make a distinction, but this is not sufficient. +</I>><i> A maintainer can be very active in cauldron but not care about maintaining +</I>><i> for stable releases. A package can have no maintainer but be actively +</I>><i> supported in practice (by everybody in cauldron, by security team in +</I>><i> stable releases). +</I>><i> +</I>><i> The current main vs contrib approach in mandriva is very sensible. It has some (minor, to me) +</I>><i> drawbacks, but when I install packages from main I *know* there will be security updates, +</I>><i> bugfix updates, and a QA process that packages in contrib don't have. +</I> +Since we pull lots of deps ( like perl module, python module ) to ensure +that everything build fine without any formal check of packages, I can +ensure you that packages in main do not have more QA process than +anything. + +What is checked is a list of functionality in the default installation. +Not every possible feature using every possible package in main. + + +Almost all community distros have found that what you call "minor" +drawbacks are in fact not a good idea. Fedora merged core and extras. +Debian never did the split, Gentoo either. The split is usually just a +reminiscence of the commercial nature of the main sponsor ( Mandriva, +Ubuntu ). + +Let me remind the problems that we are having with the split, as they +are not so minor : +- complexity on build system side to take in account this + - packagers time lost to understand what going on when self + containment is broken. Older ones do not have the problem ( or at + least, know it ), but newer one sooner or later does. + +- complexity on the users system as they need to have twice the number + of media to cope with this. This also appear in the interface of + various tools, and it is imho uneeded. Most people will say that we + already have too much medias. + +- complexity because users do not understand it. If we tell + +- time lost managing it. moving from contribs to main, and cleaning + main. Main cleaning that is seldomly done because : + - no one has time to do it + - people fiercly defend the inclusion of their favorite software in + main + +- time lost because packagers have to wait on overloaded sysadmin to do + the move + +- complexity over time of support because package move from main to + contribs and viceversa. Especially when there is some backports from + a software in main that would requires a software in contribs, etc. + + + +><i> Do we plan to have no QA process at all in Mageia ? +</I> +You should not use this kind of formulation, this is FUD. + +><i> If we plan to have such processes, does the merge between core and extra +</I>><i> make is efficient ? I guess we don't plan to have all packages (even +</I>><i> maintained ones) equally supported with a full QA process (doesn't seem realistic) ? +</I> +Again, reread the mail I sent. This is a user concern, not a mirror +admin concern. As such, it should not leak on mirror organisation, +neither on BS organisation. +And the filtering proposal I made could perfectly fit, provided we find +a way to get the "QA note" for a package. Maybe a webapp, with + +If some users only want to have only "QA approved package", that's +rather easy. Just install nothing outside of the default set of +packages. + +><i> Packages in core get the "QA approved" stamp whereas packages in extra get none. +</I> +The self containment requirement would make it very hard to get such QA +approved stamp. + +We cannot have a package being tested without doing the same for its +requires first. And we cannot say that we support a package without +supporting the full requires. + +Look at openoffice at Mandriva. It does requires +tomcat5-servlet-2.4-api, hsqldb on 2010.1 . They are both non trivial to +test, and I am quite sure that they were not much "QA approved" besides +"openoffice work for basic tasks". And in fact, when eclipse was in +main, this was the same. + +So in order to have openoffice to have a QA approved stamp, openjdk, +tomcat and hsqldb would have one. I am pretty sure they do not had +extensive checks.. + +-- +Michael Scherer + +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001497.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001506.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1503">[ date ]</a> + <a href="thread.html#1503">[ thread ]</a> + <a href="subject.html#1503">[ subject ]</a> + <a href="author.html#1503">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001504.html b/zarb-ml/mageia-dev/20101129/001504.html new file mode 100644 index 000000000..6e870df26 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001504.html @@ -0,0 +1,105 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129141047.GA8311%40mongueurs.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001523.html"> + <LINK REL="Next" HREF="001505.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Jerome Quelin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129141047.GA8311%40mongueurs.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">jquelin at gmail.com + </A><BR> + <I>Mon Nov 29 15:10:47 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001523.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001505.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1504">[ date ]</a> + <a href="thread.html#1504">[ thread ]</a> + <a href="subject.html#1504">[ subject ]</a> + <a href="author.html#1504">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On 10/11/28 22:12 +0200, Thomas Backlund wrote: +><i> So the mirror medias accordingly to all comments so far would be a simple: +</I>><i> +</I>><i> * core +</I>><i> - enabled by default +</I>><i> - mirrors must mirror this media to be listed as a mirror +</I>><i> - only GPL stuff +</I>><i> - must be selfcontained +</I>><i> +</I>><i> * nonfree +</I>><i> - disabled by default, installer will ask to enable it if +</I>><i> it detects hw that need driver/fw from here... +</I>><i> - mirrors must mirror this media to be listed as a mirror +</I>><i> - contains apps/drivers/firmware that are free to redistribute, +</I>><i> but we dont have GPL source for +</I>><i> - for example ati/nvidia drivers/firmware, Oracle Java, ... +</I>><i> +</I>><i> * tainted +</I>><i> - disabled by default +</I>><i> - mirrors are free to not mirror this media +</I>><i> - stuff we think we can redistribute, but that may have some +</I>><i> patent issues or other restrictions in oter countries. +</I> +as a packager, i like this. +as a user, i like this too. +i let mirror admins comment wrt their view. + +jérôme +-- +<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">jquelin at gmail.com</A> +</PRE> + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001523.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001505.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1504">[ date ]</a> + <a href="thread.html#1504">[ thread ]</a> + <a href="subject.html#1504">[ subject ]</a> + <a href="author.html#1504">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001505.html b/zarb-ml/mageia-dev/20101129/001505.html new file mode 100644 index 000000000..8e5b829eb --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001505.html @@ -0,0 +1,100 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3Cop.vmxrg710ct0cxl%40kira-notebook%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001504.html"> + <LINK REL="Next" HREF="001508.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Kira</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3Cop.vmxrg710ct0cxl%40kira-notebook%3E" + TITLE="[Mageia-dev] Mirror layout, round two">elegant.pegasus at gmail.com + </A><BR> + <I>Mon Nov 29 15:20:58 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001504.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001508.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1505">[ date ]</a> + <a href="thread.html#1505">[ thread ]</a> + <a href="subject.html#1505">[ subject ]</a> + <a href="author.html#1505">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>在 Mon, 29 Nov 2010 22:10:47 +0800, Jerome Quelin <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">jquelin at gmail.com</A>>寫道: +>><i> * core +</I>>><i> - enabled by default +</I>>><i> - mirrors must mirror this media to be listed as a mirror +</I>>><i> - only GPL stuff +</I>>><i> - must be selfcontained +</I>>><i> +</I>>><i> * nonfree +</I>>><i> - disabled by default, installer will ask to enable it if +</I>>><i> it detects hw that need driver/fw from here... +</I>>><i> - mirrors must mirror this media to be listed as a mirror +</I>>><i> - contains apps/drivers/firmware that are free to redistribute, +</I>>><i> but we dont have GPL source for +</I>>><i> - for example ati/nvidia drivers/firmware, Oracle Java, ... +</I>>><i> +</I>>><i> * tainted +</I>>><i> - disabled by default +</I>>><i> - mirrors are free to not mirror this media +</I>>><i> - stuff we think we can redistribute, but that may have some +</I>>><i> patent issues or other restrictions in oter countries. +</I>><i> +</I>><i> as a packager, i like this. +</I>><i> as a user, i like this too. +</I>><i> i let mirror admins comment wrt their view. +</I>I like this scheme, very clear and easy to understand for everyone. +</PRE> + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001504.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001508.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1505">[ date ]</a> + <a href="thread.html#1505">[ thread ]</a> + <a href="subject.html#1505">[ subject ]</a> + <a href="author.html#1505">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001506.html b/zarb-ml/mageia-dev/20101129/001506.html new file mode 100644 index 000000000..6825e35eb --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001506.html @@ -0,0 +1,166 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291524.04254.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001503.html"> + <LINK REL="Next" HREF="001507.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291524.04254.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 15:24:04 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001503.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001507.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1506">[ date ]</a> + <a href="thread.html#1506">[ thread ]</a> + <a href="subject.html#1506">[ subject ]</a> + <a href="author.html#1506">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit : +><i> +</I>><i> Le lundi 29 novembre 2010 à 13:14 +0100, Samuel Verschelde a écrit : +</I>><i> > +</I>><i> > It was said early that you just have to look at whether the package +</I>><i> > has a maintainer or not to make a distinction, but this is not sufficient. +</I>><i> > A maintainer can be very active in cauldron but not care about maintaining +</I>><i> > for stable releases. A package can have no maintainer but be actively +</I>><i> > supported in practice (by everybody in cauldron, by security team in +</I>><i> > stable releases). +</I>><i> > +</I>><i> > The current main vs contrib approach in mandriva is very sensible. It has some (minor, to me) +</I>><i> > drawbacks, but when I install packages from main I *know* there will be security updates, +</I>><i> > bugfix updates, and a QA process that packages in contrib don't have. +</I>><i> +</I>><i> Since we pull lots of deps ( like perl module, python module ) to ensure +</I>><i> that everything build fine without any formal check of packages, I can +</I>><i> ensure you that packages in main do not have more QA process than +</I>><i> anything. +</I> +May be true until the final freeze. Once the freeze happens there is a formal QA process for security and bugfix updates. That's what my post revolved around. + +><i> Let me remind the problems that we are having with the split, as they +</I>><i> are not so minor : +</I>><i> - complexity on build system side to take in account this +</I>><i> - packagers time lost to understand what going on when self +</I>><i> containment is broken. Older ones do not have the problem ( or at +</I>><i> least, know it ), but newer one sooner or later does. +</I> +That's also what allows to block easily unwanted updates on main packages for stable releases. + +><i> - complexity on the users system as they need to have twice the number +</I>><i> of media to cope with this. This also appear in the interface of +</I>><i> various tools, and it is imho uneeded. Most people will say that we +</I>><i> already have too much medias. +</I> +Indeed, however it helps showing that there's a set of packages which is supported, and another one which is only on behalf of the maintainer. In a community driven distribution, this distinction may remains valid : some packages are officially supported by the distribution, others may or may not be, depending on the maintainer (or lack of maintainer). + +The main complexity in current media in Mandriva comes from the updates/backports/testing/debug packages which multiply the number of visible media, but this can be drastically improved on UI side. + + +><i> - time lost managing it. moving from contribs to main, and cleaning +</I>><i> main. Main cleaning that is seldomly done because : +</I>><i> - no one has time to do it +</I>><i> - people fiercly defend the inclusion of their favorite software in +</I>><i> main +</I> +If maintaining a package in main means a real committment to support it, with proper rules and management it seems doable to have it work better than it used to at Mandriva. + +><i> - time lost because packagers have to wait on overloaded sysadmin to do +</I>><i> the move +</I> +Let's give the ability to more people to do the move ? + +><i> - complexity over time of support because package move from main to +</I>><i> contribs and viceversa. Especially when there is some backports from +</I>><i> a software in main that would requires a software in contribs, etc. +</I> +Indeed, this is a pain :) + +><i> > Do we plan to have no QA process at all in Mageia ? +</I>><i> +</I>><i> You should not use this kind of formulation, this is FUD. +</I> +It was a rhetorical question, as you can guess from what followed just after that. At least it was intended as such. I remove it if it was too FUDist :) +As a side note, I should have said "stable release support" rather that QA. + +><i> > If we plan to have such processes, does the merge between core and extra +</I>><i> > make is efficient ? I guess we don't plan to have all packages (even +</I>><i> > maintained ones) equally supported with a full QA process (doesn't seem realistic) ? +</I>><i> +</I>><i> Again, reread the mail I sent. This is a user concern, not a mirror +</I>><i> admin concern. As such, it should not leak on mirror organisation, +</I>><i> neither on BS organisation. +</I>><i> And the filtering proposal I made could perfectly fit, provided we find +</I>><i> a way to get the "QA note" for a package. Maybe a webapp, with +</I>><i> +</I> +If there's a way to really flag packages as supported, so that we can query the RPM database and know if a package is supported or not, and do it easily (as a user), then I have nothing more against merging core and extras. + +In fact, mirror structure and processes (including QA and support) are related, and the decision to merge core and extras must be taken together with decisions on QA and support processes, so that we don't end up with a situation were no one knows what's supported or not because the media separation disappeared. Without such processes I should remain against the merge. + + +><i> > Packages in core get the "QA approved" stamp whereas packages in extra get none. +</I>><i> +</I>><i> The self containment requirement would make it very hard to get such QA +</I>><i> approved stamp. +</I>><i> +</I>><i> We cannot have a package being tested without doing the same for its +</I>><i> requires first. And we cannot say that we support a package without +</I>><i> supporting the full requires. +</I>><i> +</I>><i> Look at openoffice at Mandriva. It does requires +</I>><i> tomcat5-servlet-2.4-api, hsqldb on 2010.1 . They are both non trivial to +</I>><i> test, and I am quite sure that they were not much "QA approved" besides +</I>><i> "openoffice work for basic tasks". And in fact, when eclipse was in +</I>><i> main, this was the same. +</I>><i> +</I>><i> So in order to have openoffice to have a QA approved stamp, openjdk, +</I>><i> tomcat and hsqldb would have one. I am pretty sure they do not had +</I>><i> extensive checks.. +</I> +The "QA approved" stamps, in my mind, means : "there no known blocking bug or security issue, and if we find some after the release, we'll fix them rapidly". This is more a guarantee of support than a guarantee of quality. + +Regards + +Samuel Verschelde + +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001503.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001507.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1506">[ date ]</a> + <a href="thread.html#1506">[ thread ]</a> + <a href="subject.html#1506">[ subject ]</a> + <a href="author.html#1506">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001507.html b/zarb-ml/mageia-dev/20101129/001507.html new file mode 100644 index 000000000..8561db752 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001507.html @@ -0,0 +1,73 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291531.03182.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001506.html"> + <LINK REL="Next" HREF="001512.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291531.03182.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 15:31:03 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001506.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001512.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1507">[ date ]</a> + <a href="thread.html#1507">[ thread ]</a> + <a href="subject.html#1507">[ subject ]</a> + <a href="author.html#1507">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le lundi 29 novembre 2010 15:24:04, Samuel Verschelde a écrit : +><i> +</I>><i> Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit : +</I>><i> > - complexity over time of support because package move from main to +</I>><i> > contribs and viceversa. Especially when there is some backports from +</I>><i> > a software in main that would requires a software in contribs, etc. +</I>><i> +</I>><i> Indeed, this is a pain :) +</I>><i> +</I> +It's a pain, but the policy saying a supported package must rely on other supported packages is not totally bad. I hope whatever the mirror structure we will enforce such a policy (with changes maybe, or exceptions). + +Samuel + +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001506.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001512.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1507">[ date ]</a> + <a href="thread.html#1507">[ thread ]</a> + <a href="subject.html#1507">[ subject ]</a> + <a href="author.html#1507">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001508.html b/zarb-ml/mageia-dev/20101129/001508.html new file mode 100644 index 000000000..67aa284e4 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001508.html @@ -0,0 +1,89 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3CAANLkTikNY9yvrQC9oBmV4PqOBQYf%3D-7ygW-EOM4_Zr0d%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="001505.html"> + <LINK REL="Next" HREF="001524.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Dexter Morgan</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3CAANLkTikNY9yvrQC9oBmV4PqOBQYf%3D-7ygW-EOM4_Zr0d%40mail.gmail.com%3E" + TITLE="[Mageia-dev] Mirror layout, round two">dmorganec at gmail.com + </A><BR> + <I>Mon Nov 29 15:44:43 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001505.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001524.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1508">[ date ]</a> + <a href="thread.html#1508">[ thread ]</a> + <a href="subject.html#1508">[ subject ]</a> + <a href="author.html#1508">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Mon, Nov 29, 2010 at 3:10 PM, Jerome Quelin <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">jquelin at gmail.com</A>> wrote: +><i> On 10/11/28 22:12 +0200, Thomas Backlund wrote: +</I>>><i> So the mirror medias accordingly to all comments so far would be a simple: +</I>>><i> +</I>>><i> * core +</I>>><i>   - enabled by default +</I>>><i>   - mirrors must mirror this media to be listed as a mirror +</I>>><i>   - only GPL stuff +</I>>><i>   - must be selfcontained +</I> +I liked the main/contrib separation. +Main was officially supported + sec updates and with only core this +means a lot more work/support. + + +the other part ( non free + tainted ) seems OK for me +</PRE> + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001505.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001524.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1508">[ date ]</a> + <a href="thread.html#1508">[ thread ]</a> + <a href="subject.html#1508">[ subject ]</a> + <a href="author.html#1508">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001509.html b/zarb-ml/mageia-dev/20101129/001509.html new file mode 100644 index 000000000..fd8cf44d5 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001509.html @@ -0,0 +1,88 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129160236.GI21938%40mars-attacks.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001517.html"> + <LINK REL="Next" HREF="001511.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>nicolas vigier</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129160236.GI21938%40mars-attacks.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">boklm at mars-attacks.org + </A><BR> + <I>Mon Nov 29 17:02:36 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001517.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001511.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1509">[ date ]</a> + <a href="thread.html#1509">[ thread ]</a> + <a href="subject.html#1509">[ subject ]</a> + <a href="author.html#1509">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Mon, 29 Nov 2010, Samuel Verschelde wrote: + +><i> +</I>><i> Indeed, however it helps showing that there's a set of packages which is supported, and another one which is only on behalf of the maintainer. In a community driven distribution, this distinction may remains valid : some packages are officially supported by the distribution, others may or may not be, depending on the maintainer (or lack of maintainer). +</I> +We don't need separate medias to show that there are two sets of +packages, supported and unsupported. I think using separate medias adds +useless complexity. We could for instance provide a file on api.mageia.org +containing the list of officially supported packages. It would also have +other advantages : + - You can see how many unsupported packages and which ones are installed + on your system. This is not possible with main/contrib, if you enabled + contrib temporarly to install a few packages. + - You can change the package status (supported/unsupported) after the + release, if needed. + - Some packages can have a different support time. On Mandriva, "Base + system & components" was supported longer, but it was not clear which + packages were part of this. + - This file could also list known security issues for unsupported + and supported packages. + - Some packages have a lot of optional plugins, and we build them all, + adding a lot of build requires. With main/contrib separation we need + to add all the build dependencies to main, even if most of them are + not runtime dependencies. + +</PRE> + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001517.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001511.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1509">[ date ]</a> + <a href="thread.html#1509">[ thread ]</a> + <a href="subject.html#1509">[ subject ]</a> + <a href="author.html#1509">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001510.html b/zarb-ml/mageia-dev/20101129/001510.html new file mode 100644 index 000000000..d6316945b --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001510.html @@ -0,0 +1,285 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1291046905.8266.173.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001525.html"> + <LINK REL="Next" HREF="001516.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C1291046905.8266.173.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">misc at zarb.org + </A><BR> + <I>Mon Nov 29 17:08:25 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1510">[ date ]</a> + <a href="thread.html#1510">[ thread ]</a> + <a href="subject.html#1510">[ subject ]</a> + <a href="author.html#1510">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 29 novembre 2010 à 15:24 +0100, Samuel Verschelde a écrit : +><i> Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit : +</I>><i> > +</I>><i> > Le lundi 29 novembre 2010 à 13:14 +0100, Samuel Verschelde a écrit : +</I>><i> > > +</I>><i> > > It was said early that you just have to look at whether the package +</I>><i> > > has a maintainer or not to make a distinction, but this is not sufficient. +</I>><i> > > A maintainer can be very active in cauldron but not care about maintaining +</I>><i> > > for stable releases. A package can have no maintainer but be actively +</I>><i> > > supported in practice (by everybody in cauldron, by security team in +</I>><i> > > stable releases). +</I>><i> > > +</I>><i> > > The current main vs contrib approach in mandriva is very sensible. It has some (minor, to me) +</I>><i> > > drawbacks, but when I install packages from main I *know* there will be security updates, +</I>><i> > > bugfix updates, and a QA process that packages in contrib don't have. +</I>><i> > +</I>><i> > Since we pull lots of deps ( like perl module, python module ) to ensure +</I>><i> > that everything build fine without any formal check of packages, I can +</I>><i> > ensure you that packages in main do not have more QA process than +</I>><i> > anything. +</I>><i> +</I>><i> May be true until the final freeze. Once the freeze happens there is a formal +</I>><i> QA process for security and bugfix updates. That's what my post revolved around. +</I> +And how having 1 merged media prevent this process ? + + +><i> > Let me remind the problems that we are having with the split, as they +</I>><i> > are not so minor : +</I>><i> > - complexity on build system side to take in account this +</I>><i> > - packagers time lost to understand what going on when self +</I>><i> > containment is broken. Older ones do not have the problem ( or at +</I>><i> > least, know it ), but newer one sooner or later does. +</I>><i> +</I>><i> That's also what allows to block easily unwanted updates on main packages for stable releases. +</I> +I think you misunderstood me. +I speak of the fact that in cooker, people add BuildRequires in contribs +for a package in main and get puzzled by the error message. Granted, we +need to improve the error message, but that still make us lose time. +( and the fact that no one did improve the message is imho sign that +this is not annoying enough, to warrant a patch, yet annoying enough to +lose people ) + +><i> > - complexity on the users system as they need to have twice the number +</I>><i> > of media to cope with this. This also appear in the interface of +</I>><i> > various tools, and it is imho uneeded. Most people will say that we +</I>><i> > already have too much medias. +</I>><i> +</I>><i> Indeed, however it helps showing that there's a set of packages which is supported, +</I>><i> and another one which is only on behalf of the maintainer. In a community driven +</I>><i> distribution, this distinction may remains valid : some packages are officially +</I>><i> supported by the distribution, others may or may not be, depending on the maintainer +</I>><i> (or lack of maintainer). +</I> +If there is a maintainer and he has a account, then it is a official +one, and so the package is officially supported. That's all. There is no +separation of "the organisation" and "the maintainers", we are not +Mandriva. + +So either the package is supported, and we keep, or it is not, and then +why should we keep it ? + + +><i> The main complexity in current media in Mandriva comes from the updates/backports/testing/debug +</I>><i> packages which multiply the number of visible media, but this can be drastically improved on UI side. +</I> +That's exactly what i told 3 mails ago.... +I have also added that we cannot do miracles on ui if we keep pushing +for more complexity. + +><i> +</I>><i> > - time lost managing it. moving from contribs to main, and cleaning +</I>><i> > main. Main cleaning that is seldomly done because : +</I>><i> > - no one has time to do it +</I>><i> > - people fiercly defend the inclusion of their favorite software in +</I>><i> > main +</I>><i> +</I>><i> If maintaining a package in main means a real committment to support it, +</I>><i> with proper rules and management it seems doable to have it work better +</I>><i> than it used to at Mandriva. +</I> +It was already the case at Mandriva. But it didn't work. What step do +you propose to avoid the same pitfall ( ie, packages pushed in main +without checking first with support team, packages never cleaned because +that's a hard job, endless bickering on what goes in main or contribs ) + +><i> > - time lost because packagers have to wait on overloaded sysadmin to do +</I>><i> > the move +</I>><i> +</I>><i> Let's give the ability to more people to do the move ? +</I> +Then they would push what they want without consideration of support. +See the previous paragraph. + +><i> > > If we plan to have such processes, does the merge between core and extra +</I>><i> > > make is efficient ? I guess we don't plan to have all packages (even +</I>><i> > > maintained ones) equally supported with a full QA process (doesn't seem realistic) ? +</I>><i> > +</I>><i> > Again, reread the mail I sent. This is a user concern, not a mirror +</I>><i> > admin concern. As such, it should not leak on mirror organisation, +</I>><i> > neither on BS organisation. +</I>><i> > And the filtering proposal I made could perfectly fit, provided we find +</I>><i> > a way to get the "QA note" for a package. Maybe a webapp, with +</I>><i> > +</I>><i> +</I>><i> If there's a way to really flag packages as supported, so that we can +</I>><i> query the RPM database and know if a package is supported or not, and +</I>><i> do it easily (as a user), then I have nothing more against merging +</I>><i> core and extras. +</I> +Why in the rpm db ? +A external file would perfectly do the trick. The same goes for +maintainers. The only thing needed is less talk and more code. + + + +><i> In fact, mirror structure and processes (including QA and support) are +</I>><i> related, +</I> +No. That's because you think that mirror structure is the only way we +have to act on urpmi config. And that shouldn't be, because we can't +support every possible distinction that everybody want without a +complexity explosion. See what I said in the mail. + +><i> and the decision to merge core and extras must be taken together +</I>><i> with decisions on QA and support processes, +</I> +Well, everything should be supported or dropped, that's all. Easy, done +by every other distros out there except those that place a artificial +separation. If there is a security bug opened and no one act on it after +a time, let's drop the package. If there is a severe bug and no one act, +the same, let's drop it. + +If people want to resurrect a rpm, they can, there is a svn for that. + + +And if we want to wait on the QA team for defining the mirror structure, +then we will have a loop ( qa team requires a distro to start and be +launched, a distro requires a BS the bs requires mirror structure, and +so mirror can't depend on QA or we will never start ). + +><i> so that we don't end up with +</I>><i> a situation were no one knows what's supported or not because the media +</I>><i> separation disappeared. Without such processes I should remain against the merge. +</I> +That's already the case at Mandriva. See for example +<A HREF="http://lists.mandriva.com/kernel-discuss/2010-10/msg00000.php">http://lists.mandriva.com/kernel-discuss/2010-10/msg00000.php</A> + +We _already_ do not know what is supported or not at Mandriva. People +push update to contribs ( I do push them for tor or puppet ), while some +packages in main are not updated or buggy or simply unrebuildable ( see +all mdk rpm still in the distro for long forgotten reasons ). See this +old long standing pdftk bug caused by a issue in the java stack in +main : <A HREF="https://qa.mandriva.com/show_bug.cgi?id=44372">https://qa.mandriva.com/show_bug.cgi?id=44372</A> . In main, and no +one did anything. + +There is also lots of duplication : +- apache & nginx, who was moved to main likely because oden like nginx, +- the various ftp servers, +- sendmail & postfix, +- the 4 tls/ssl implementation, +- the 2 html rendering library ( webkit, gecko ) with more than 1 +browser. + + +And most people tend to simply not care to the difference between main +and contribs. If you decide to use puppet for technical reasons ( as we +did in sysadm team ), I doubt you will switch to another tool because it +is in contribs. People install web applications without using the distro +rpm also because they do not care enough about official support ( this +and maybe other reason ). + +And in the end, I think most people just keep contribs and main, and +forget the difference. + +Those that care more just take a support contact at Mandriva, and with +enough money, anything can be supported. And there is not really a 1 to +1 mapping between "supported" and "main". + +So the split did not help much on this regard at all. It just give a +false sense of security and more complexity on the distro side. + +><i> > > Packages in core get the "QA approved" stamp whereas packages in extra get none. +</I>><i> > +</I>><i> > The self containment requirement would make it very hard to get such QA +</I>><i> > approved stamp. +</I>><i> > +</I>><i> > We cannot have a package being tested without doing the same for its +</I>><i> > requires first. And we cannot say that we support a package without +</I>><i> > supporting the full requires. +</I>><i> > +</I>><i> > Look at openoffice at Mandriva. It does requires +</I>><i> > tomcat5-servlet-2.4-api, hsqldb on 2010.1 . They are both non trivial to +</I>><i> > test, and I am quite sure that they were not much "QA approved" besides +</I>><i> > "openoffice work for basic tasks". And in fact, when eclipse was in +</I>><i> > main, this was the same. +</I>><i> > +</I>><i> > So in order to have openoffice to have a QA approved stamp, openjdk, +</I>><i> > tomcat and hsqldb would have one. I am pretty sure they do not had +</I>><i> > extensive checks.. +</I>><i> +</I>><i> The "QA approved" stamps, in my mind, means : "there no known blocking bug or +</I>><i> security issue, and if we find some after the release, we'll fix them rapidly". +</I>><i> This is more a guarantee of support than a guarantee of quality. +</I> +Again, I am not sure that hsqldb, being unmaintained, would be +supported. + +And there is know bugs that were not fixed rapidly in main ( see the +pdftk example I gave for the most notorious one ). + +So let's be honest, let's don't start by doing promise we can't keep for +the moment. + +-- +Michael Scherer + +</PRE> + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1510">[ date ]</a> + <a href="thread.html#1510">[ thread ]</a> + <a href="subject.html#1510">[ subject ]</a> + <a href="author.html#1510">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001511.html b/zarb-ml/mageia-dev/20101129/001511.html new file mode 100644 index 000000000..ea696959b --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001511.html @@ -0,0 +1,97 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291708.57379.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001509.html"> + <LINK REL="Next" HREF="001519.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291708.57379.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 17:08:54 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001509.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001519.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1511">[ date ]</a> + <a href="thread.html#1511">[ thread ]</a> + <a href="subject.html#1511">[ subject ]</a> + <a href="author.html#1511">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le lundi 29 novembre 2010 17:02:36, nicolas vigier a écrit : +><i> +</I>><i> On Mon, 29 Nov 2010, Samuel Verschelde wrote: +</I>><i> +</I>><i> > +</I>><i> > Indeed, however it helps showing that there's a set of packages which is supported, and another one which is only on behalf of the maintainer. In a community driven distribution, this distinction may remains valid : some packages are officially supported by the distribution, others may or may not be, depending on the maintainer (or lack of maintainer). +</I>><i> +</I>><i> We don't need separate medias to show that there are two sets of +</I>><i> packages, supported and unsupported. I think using separate medias adds +</I>><i> useless complexity. We could for instance provide a file on api.mageia.org +</I>><i> containing the list of officially supported packages. It would also have +</I>><i> other advantages : +</I>><i> - You can see how many unsupported packages and which ones are installed +</I>><i> on your system. This is not possible with main/contrib, if you enabled +</I>><i> contrib temporarly to install a few packages. +</I>><i> - You can change the package status (supported/unsupported) after the +</I>><i> release, if needed. +</I>><i> - Some packages can have a different support time. On Mandriva, "Base +</I>><i> system & components" was supported longer, but it was not clear which +</I>><i> packages were part of this. +</I>><i> - This file could also list known security issues for unsupported +</I>><i> and supported packages. +</I>><i> - Some packages have a lot of optional plugins, and we build them all, +</I>><i> adding a lot of build requires. With main/contrib separation we need +</I>><i> to add all the build dependencies to main, even if most of them are +</I>><i> not runtime dependencies. +</I>><i> +</I> +Indeed maintaining the list of supported packages outside the repository is an interesting approach (better yet that misc's tag based proposal, I think). + +Regards + +Samuel Verschelde + +</PRE> + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001509.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001519.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1511">[ date ]</a> + <a href="thread.html#1511">[ thread ]</a> + <a href="subject.html#1511">[ subject ]</a> + <a href="author.html#1511">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001512.html b/zarb-ml/mageia-dev/20101129/001512.html new file mode 100644 index 000000000..42396b617 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001512.html @@ -0,0 +1,93 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129161108.GA7479%40virgo.home.nanardon.zarb.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001507.html"> + <LINK REL="Next" HREF="001513.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Olivier Thauvin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129161108.GA7479%40virgo.home.nanardon.zarb.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">nanardon at nanardon.zarb.org + </A><BR> + <I>Mon Nov 29 17:11:08 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001507.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001513.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1512">[ date ]</a> + <a href="thread.html#1512">[ thread ]</a> + <a href="subject.html#1512">[ subject ]</a> + <a href="author.html#1512">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>* Samuel Verschelde (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>) wrote: +><i> +</I>><i> Le lundi 29 novembre 2010 15:24:04, Samuel Verschelde a écrit : +</I>><i> > +</I>><i> > Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit : +</I>><i> > > - complexity over time of support because package move from main to +</I>><i> > > contribs and viceversa. Especially when there is some backports from +</I>><i> > > a software in main that would requires a software in contribs, etc. +</I>><i> > +</I>><i> > Indeed, this is a pain :) +</I>><i> > +</I>><i> +</I>><i> It's a pain, but the policy saying a supported package must rely on other supported packages is not totally bad. I hope whatever the mirror structure we will enforce such a policy (with changes maybe, or exceptions). +</I> +IMHO, the mirror structure do not have to be designed to reflect logical +structure. At least until someone write a multidimensionnal filesystem +able to represent all link rpms can have between them. + +(/me is thinking he had a wonderfull idea: ls '/deps/provides/rpm > 4.4' +I'll introduce this into Sophie ! :) + +><i> +</I>><i> Samuel +</I>><i> +</I>-- + +Olivier Thauvin +CNRS - LATMOS +♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20101129/c45496eb/attachment.asc> +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001507.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001513.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1512">[ date ]</a> + <a href="thread.html#1512">[ thread ]</a> + <a href="subject.html#1512">[ subject ]</a> + <a href="author.html#1512">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001513.html b/zarb-ml/mageia-dev/20101129/001513.html new file mode 100644 index 000000000..8051a5641 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001513.html @@ -0,0 +1,84 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291715.39058.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001512.html"> + <LINK REL="Next" HREF="001514.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291715.39058.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 17:15:39 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001512.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001514.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1513">[ date ]</a> + <a href="thread.html#1513">[ thread ]</a> + <a href="subject.html#1513">[ subject ]</a> + <a href="author.html#1513">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le lundi 29 novembre 2010 17:11:08, Olivier Thauvin a écrit : +><i> * Samuel Verschelde (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>) wrote: +</I>><i> > +</I>><i> > Le lundi 29 novembre 2010 15:24:04, Samuel Verschelde a écrit : +</I>><i> > > +</I>><i> > > Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit : +</I>><i> > > > - complexity over time of support because package move from main to +</I>><i> > > > contribs and viceversa. Especially when there is some backports from +</I>><i> > > > a software in main that would requires a software in contribs, etc. +</I>><i> > > +</I>><i> > > Indeed, this is a pain :) +</I>><i> > > +</I>><i> > +</I>><i> > It's a pain, but the policy saying a supported package must rely on other supported packages is not totally bad. I hope whatever the mirror structure we will enforce such a policy (with changes maybe, or exceptions). +</I>><i> +</I>><i> IMHO, the mirror structure do not have to be designed to reflect logical +</I>><i> structure. At least until someone write a multidimensionnal filesystem +</I>><i> able to represent all link rpms can have between them. +</I>><i> +</I> +Same opinion here. This poorly written english sentence meant that, independently of the mirror structure, I hope such a policy will be adopted. + +Regards + +Samuel + +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001512.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001514.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1513">[ date ]</a> + <a href="thread.html#1513">[ thread ]</a> + <a href="subject.html#1513">[ subject ]</a> + <a href="author.html#1513">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001514.html b/zarb-ml/mageia-dev/20101129/001514.html new file mode 100644 index 000000000..03fa75996 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001514.html @@ -0,0 +1,78 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129161807.GB7479%40virgo.home.nanardon.zarb.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001513.html"> + <LINK REL="Next" HREF="001515.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Olivier Thauvin</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129161807.GB7479%40virgo.home.nanardon.zarb.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">nanardon at nanardon.zarb.org + </A><BR> + <I>Mon Nov 29 17:18:07 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001513.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001515.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1514">[ date ]</a> + <a href="thread.html#1514">[ thread ]</a> + <a href="subject.html#1514">[ subject ]</a> + <a href="author.html#1514">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>* Samuel Verschelde (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>) wrote: +><i> +</I>><i> +</I>><i> Same opinion here. This poorly written english sentence meant that, independently of the mirror structure, I hope such a policy will be adopted. +</I> +What do you mean by 'This poorly written english sentence' ? + +Is my english so bad ? :) + +-- + +Olivier Thauvin +CNRS - LATMOS +♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: not available +Type: application/pgp-signature +Size: 197 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20101129/b84586bd/attachment.asc> +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001513.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001515.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1514">[ date ]</a> + <a href="thread.html#1514">[ thread ]</a> + <a href="subject.html#1514">[ subject ]</a> + <a href="author.html#1514">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001515.html b/zarb-ml/mageia-dev/20101129/001515.html new file mode 100644 index 000000000..25b3fc718 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001515.html @@ -0,0 +1,75 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291756.38423.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001514.html"> + <LINK REL="Next" HREF="001517.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291756.38423.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 17:56:38 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001514.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001517.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1515">[ date ]</a> + <a href="thread.html#1515">[ thread ]</a> + <a href="subject.html#1515">[ subject ]</a> + <a href="author.html#1515">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le lundi 29 novembre 2010 17:18:07, Olivier Thauvin a écrit : +><i> * Samuel Verschelde (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>) wrote: +</I>><i> > +</I>><i> > +</I>><i> > Same opinion here. This poorly written english sentence meant that, independently of the mirror structure, I hope such a policy will be adopted. +</I>><i> +</I>><i> What do you mean by 'This poorly written english sentence' ? +</I>><i> +</I>><i> Is my english so bad ? :) +</I>><i> +</I> +No, it was my sentence which was poorly written :) + +I'll let someone else judge your english :) + +Samuel + +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001514.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001517.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1515">[ date ]</a> + <a href="thread.html#1515">[ thread ]</a> + <a href="subject.html#1515">[ subject ]</a> + <a href="author.html#1515">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001516.html b/zarb-ml/mageia-dev/20101129/001516.html new file mode 100644 index 000000000..ebf4335c5 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001516.html @@ -0,0 +1,181 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291829.35100.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001510.html"> + <LINK REL="Next" HREF="001521.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291829.35100.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">stormi at laposte.net + </A><BR> + <I>Mon Nov 29 18:29:35 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001510.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001521.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1516">[ date ]</a> + <a href="thread.html#1516">[ thread ]</a> + <a href="subject.html#1516">[ subject ]</a> + <a href="author.html#1516">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE> +Le lundi 29 novembre 2010 17:08:25, Michael Scherer a écrit : +><i> +</I>><i> Le lundi 29 novembre 2010 à 15:24 +0100, Samuel Verschelde a écrit : +</I>><i> > Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit : +</I>><i> > > - complexity on the users system as they need to have twice the number +</I>><i> > > of media to cope with this. This also appear in the interface of +</I>><i> > > various tools, and it is imho uneeded. Most people will say that we +</I>><i> > > already have too much medias. +</I>><i> > +</I>><i> > Indeed, however it helps showing that there's a set of packages which is supported, +</I>><i> > and another one which is only on behalf of the maintainer. In a community driven +</I>><i> > distribution, this distinction may remains valid : some packages are officially +</I>><i> > supported by the distribution, others may or may not be, depending on the maintainer +</I>><i> > (or lack of maintainer). +</I>><i> +</I>><i> If there is a maintainer and he has a account, then it is a official +</I>><i> one, and so the package is officially supported. That's all. There is no +</I>><i> separation of "the organisation" and "the maintainers", we are not +</I>><i> Mandriva. +</I>><i> +</I>><i> So either the package is supported, and we keep, or it is not, and then +</I>><i> why should we keep it ? +</I> +Because it works, at least partially. Because it has users. It may have flaws, it may not have the latest security fixes, it may just be supported but only updated once a year... That's not a reason for dropping it. That's why distiction between officially supported and not officially supported is useful. There are working packages, seldom updated, which don't deserve to be dropped, but which can't be advertised as officially supported, and that's understandable. The world is not either black or white, there are many shades of grey, and that's particularly true for packages in a linux distribution. + +According to what you said, it looks like there will be only 2 kinds of packages : +- in the distribution (which would be equal to "supported") +- not in the distribution + +But we all know that there will be : +- supported, both in cauldron and stable releases (updates + backports) +- supported, both in cauldron and stable releases (updates, no backports) +- supported, in cauldron only : the maintainer only cares about cauldron and hasn't enough time to fix bugs in (to his mind) old stable releases +- the same, but some people do backports from time to time +- supported in stable releases, but dropped from the cauldron because the maintainer couldn't maintain it anymore +- has no maintainer, but works, although it may have bugs and security flaws. Has users. +- many other situations +- not in the distribution + +What I'm asking for is that we put dedicated work into ensuring packages flagged as supported have security and bugfix updates in stable releases. + + +In Mandriva, you can find many examples of packages in main which are not supported in reality, or even maybe simply don't work. You can find also many packages in contrib which are perfectly supported, in cooker as in stable releases. You gave me examples. However I see very rarely security or bugfix updates for packages in contrib for stable releases (or sometimes they go to backports), whereas there are many security fixes and bugfixes for packages in main thanks to Mandriva's security team. There really is a difference between supported packages and other, although it's far from perfect. + +If there's no difference in term of security updates between php and a random maintained game, then I won't be very confident in the distribution's quality. + +Let's say I want to install php on the stable Mageia 2011, will it be supported for security fixes and bugfixes ? For how long ? Are security fixes applied as soon as possible ? If the only answer is "is has a maintainer, so it should be supported like all the other packages", I'll probably avoid Mageia on a server. + +So this time it's not a rhetorical question : is Mageia willing to provide official support for a subset of the available packages ? + +Flagging some packages as officially supported is a matter of putting dedicated resources and processes to ensure - as much as possible - good quality for those package. Like I said before, having a maintainer in itself is not sufficient, we also need support policies and a list of officially supported packages. + + +I agreed that the mirror structure is not the best way to make this distinction. An external list is good enough for that and can even bring new possibilities, as Nicolas Vigier stated in another post. + + +><i> Why in the rpm db ? +</I>><i> A external file would perfectly do the trick. The same goes for +</I>><i> maintainers. The only thing needed is less talk and more code +</I> +Okay, okay, not in the rpm db, nor in the mirror structure :) + +><i> No. That's because you think that mirror structure is the only way we +</I>><i> have to act on urpmi config. +</I> +This is what you think I think, and that's wrong. + +><i> > and the decision to merge core and extras must be taken together +</I>><i> > with decisions on QA and support processes, +</I>><i> +</I>><i> Well, everything should be supported or dropped, that's all. Easy, done +</I>><i> by every other distros out there except those that place a artificial +</I>><i> separation. If there is a security bug opened and no one act on it after +</I>><i> a time, let's drop the package. If there is a severe bug and no one act, +</I>><i> the same, let's drop it. +</I>><i> +</I>><i> If people want to resurrect a rpm, they can, there is a svn for that. +</I> +This is the most terrible thing I read so far. I already tried to answer it earlier in this message, however here's a last example : +- Someone checks if postgresql is supported because if not he'll use another distribution where it is +- It is (because every package is supported, or it's dropped), but the poor user doesn't know that Nanar went away doing his own fork, no one stepped in to maintain it ! +- One year later, postgresql has still security bugs opened, no one takes care => package is dropped + +Now if there were a list of supported packages, either it would not be officially supported and the user would know he could use it but maybe won't have security and bugfix updates, or it is officially supported. Now take the example above : +- Someone checks if postgresql is supported because if not he'll use another distribution where it is +- It is ! +- However the maintainer went away doing his own fork, so he dropped maintainership. +- Someone in QA Team rings a bell : "this supported package isn't supported anymore, but we promised we would support it for Mageia 2011 for 2 years from now ! We have to do something !" +- The package team leader, or someone else, relays the warning and finds someone else to maintain the package, at least for Mageia 2011, for security and bugfix updates. +- (another scenario : there is a maintainer, but the package has pending issues for a long time, so we have to contact the maintainer about it, and maybe find another maintainer) + +The difference is : because we said we would support it for Mageia 2011's lifetime, we do everything possible to keep this promise, and I think we can succeed provided the set of supported packages is carefully done. Things will be clearer, to my mind. + + +><i> We _already_ do not know what is supported or not at Mandriva. People +</I>><i> push update to contribs ( I do push them for tor or puppet ), while some +</I>><i> packages in main are not updated or buggy or simply unrebuildable ( see +</I>><i> all mdk rpm still in the distro for long forgotten reasons ). See this +</I>><i> old long standing pdftk bug caused by a issue in the java stack in +</I>><i> main : <A HREF="https://qa.mandriva.com/show_bug.cgi?id=44372">https://qa.mandriva.com/show_bug.cgi?id=44372</A> . In main, and no +</I>><i> one did anything. +</I> +Having packages which ought to be supported and are not in practice doesn't mean that there must be no difference between officially supported and not officially supported. + +><i> There is also lots of duplication : +</I>><i> - apache & nginx, who was moved to main likely because oden like nginx, +</I>><i> - the various ftp servers, +</I>><i> - sendmail & postfix, +</I>><i> - the 4 tls/ssl implementation, +</I>><i> - the 2 html rendering library ( webkit, gecko ) with more than 1 +</I>><i> browser. +</I> +What prevents from refining the list if it's too big ? Choosing officially supported packages is a matter of setting priorities, because we have limited resources. In what way will things be better if there is no list of officially supported packages ? + +Regards + +Samuel Verschelde + +</PRE> + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001510.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001521.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1516">[ date ]</a> + <a href="thread.html#1516">[ thread ]</a> + <a href="subject.html#1516">[ subject ]</a> + <a href="author.html#1516">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001517.html b/zarb-ml/mageia-dev/20101129/001517.html new file mode 100644 index 000000000..48124f804 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001517.html @@ -0,0 +1,81 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF3E763.90100%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001515.html"> + <LINK REL="Next" HREF="001509.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF3E763.90100%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Mon Nov 29 18:48:19 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001515.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001509.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1517">[ date ]</a> + <a href="thread.html#1517">[ thread ]</a> + <a href="subject.html#1517">[ subject ]</a> + <a href="author.html#1517">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Samuel Verschelde a écrit : +><i> +</I>><i> Le lundi 29 novembre 2010 17:18:07, Olivier Thauvin a écrit : +</I>><i> +</I>>><i> * Samuel Verschelde (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>) wrote: +</I>>><i> +</I>>>><i> +</I>>>><i> Same opinion here. This poorly written english sentence meant that, independently of the mirror structure, I hope such a policy will be adopted. +</I>>>><i> +</I>>><i> What do you mean by 'This poorly written english sentence' ? +</I>>><i> +</I>>><i> Is my english so bad ? :) +</I>>><i> +</I>>><i> +</I>><i> No, it was my sentence which was poorly written :) +</I>><i> +</I>><i> I'll let someone else judge your english :) +</I>><i> +</I>><i> Samuel +</I>><i> +</I> +The key is being understood. And perfect English grammar is no +guarantee that anyone could understand you. Don't think either of you +has anything to worry about :) + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001515.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001509.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1517">[ date ]</a> + <a href="thread.html#1517">[ thread ]</a> + <a href="subject.html#1517">[ subject ]</a> + <a href="author.html#1517">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001518.html b/zarb-ml/mageia-dev/20101129/001518.html new file mode 100644 index 000000000..954301257 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001518.html @@ -0,0 +1,76 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291925.45594.r.h.michel%2Bmageia%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001480.html"> + <LINK REL="Next" HREF="001481.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Renaud MICHEL</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011291925.45594.r.h.michel%2Bmageia%40gmail.com%3E" + TITLE="[Mageia-dev] Mirror layout, round two">r.h.michel+mageia at gmail.com + </A><BR> + <I>Mon Nov 29 19:25:45 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001480.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001481.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1518">[ date ]</a> + <a href="thread.html#1518">[ thread ]</a> + <a href="subject.html#1518">[ subject ]</a> + <a href="author.html#1518">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On lundi 29 novembre 2010 at 01:45, Olivier Thauvin wrote : +><i> * Renaud MICHEL (<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">r.h.michel+mageia at gmail.com</A>) wrote: +</I>><i> > On samedi 27 novembre 2010 at 00:02, Maarten Vanraes wrote : +</I>><i> > If the files are identical, they can be hard linked, and then the +</I>><i> > mirrors updates them with rsync -aH. +</I>><i> > (by the way, the readme already ask for those options +</I>><i> > <A HREF="http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/mirror.readme">http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/mirror.readme</A> ) +</I>><i> > It is quite easy to make a script that will make those hard links "à +</I>><i> > posteriori" (you only need to compare files with identical names) +</I>><i> +</I>><i> If you compare only the filename you'll probably link different file. To +</I>><i> do this you need at least to compare also the size. +</I> +No, I wrote to compare files *with* identical names, in the sense that there +is no need to compare files whose name differ (because they refer to another +package or another version). +But you must compare them and check they are identical bit by bit (with comp +for example). + +-- +Renaud Michel +</PRE> + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001480.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001481.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1518">[ date ]</a> + <a href="thread.html#1518">[ thread ]</a> + <a href="subject.html#1518">[ subject ]</a> + <a href="author.html#1518">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001519.html b/zarb-ml/mageia-dev/20101129/001519.html new file mode 100644 index 000000000..cc03d6acc --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001519.html @@ -0,0 +1,146 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF3F7A3.1010203%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001511.html"> + <LINK REL="Next" HREF="001520.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF3F7A3.1010203%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Mon Nov 29 19:57:39 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001511.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001520.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1519">[ date ]</a> + <a href="thread.html#1519">[ thread ]</a> + <a href="subject.html#1519">[ subject ]</a> + <a href="author.html#1519">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>nicolas vigier a écrit : +><i> On Mon, 29 Nov 2010, Samuel Verschelde wrote: +</I>><i> +</I>><i> +</I>>><i> Indeed, however it helps showing that there's a set of packages which is supported, and another one which is only on behalf of the maintainer. In a community driven distribution, this distinction may remains valid : some packages are officially supported by the distribution, others may or may not be, depending on the maintainer (or lack of maintainer). +</I>>><i> +</I> +Exactly. And remember that the proposed restriction for core was those +packages necessary to a typical desktop or server or development system, +plus a *few* very useful/widely used packages such as LibreOffice +(OpenOffice) and Firefox. +Suggested to be included was "complete desktops", which would be +somewhat subjective as well. +Outside of these potentially controversial borderline cases, what would +be in core would be well defined. +><i> We don't need separate medias to show that there are two sets of +</I>><i> packages, supported and unsupported. I think using separate medias adds +</I>><i> useless complexity. +</I>If we look at our origins, we are not adding media here. +But we are limiting what is in "core" (main). +Note that in their reorganization, Mandriva is moving in the same direction. +I see this more as a refocus of the packaging process, much like the +(very useful) addition of backports_testing. + +><i> We could for instance provide a file on api.mageia.org +</I>><i> containing the list of officially supported packages. It would also have +</I>><i> other advantages : +</I>><i> - You can see how many unsupported packages and which ones are installed +</I>><i> on your system. This is not possible with main/contrib, if you enabled +</I>><i> contrib temporarly to install a few packages. +</I>><i> +</I> +This is not really related to one or 2 groups of repositories. Although +doing that for *officially fully supported* packages should be +moderately easier with separate groups. +Note that many packages in "extra" would also be very well supported, by +the packager or official maintainer. + +The idea is not that the Mageia community would not support "extra" +packages. +It is just that if an "extra" package breaks, it shouldn't break a +user's system. +But if a "core" package breaks, we would expect that it would break many +users' systems. +Thus the priority to ensure that "core" packages are always fixed in a +timely manner. + +><i> - You can change the package status (supported/unsupported) after the +</I>><i> release, if needed. +</I>><i> +</I>If the division is well defined, we should rarely need to change a +package's status. +There will be many well supported packages in "extra". + +><i> - Some packages can have a different support time. On Mandriva, "Base +</I>><i> system& components" was supported longer, but it was not clear which +</I>><i> packages were part of this. +</I>><i> +</I>Core is proposed to be largely "base system & components". Part of the +idea is to make clearer, to everyone, which packages have an enhanced +level of support. +Support time is another (useful) question. + +><i> - This file could also list known security issues for unsupported +</I>><i> and supported packages. +</I>><i> +</I>Not related to the core/extra question, but a useful feature. For +Mageia-app-db project :) + +><i> - Some packages have a lot of optional plugins, and we build them all, +</I>><i> adding a lot of build requires. With main/contrib separation we need +</I>><i> to add all the build dependencies to main, even if most of them are +</I>><i> not runtime dependencies. +</I>><i> +</I> +We will have to be more selective for core packages, to avoid this problem. +Maybe "suggests", or other features being added with rpm5. + +I would agree that, at least in the transition, this would make more +work for packagers. +But in the longer term we will have a much more stable system. +I see this as one of the key advantages of this "core" / "extra" separation. + +(Hopefully we will also get rid of annoyances such as requiring everyone +to install thai localisations.) +(Note that Mandriva is moving to rpm5 for their next full release +(proposed for May 2011), which has more features for building rpms. +Presumably Mageia will follow.) + +- André +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001511.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001520.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1519">[ date ]</a> + <a href="thread.html#1519">[ thread ]</a> + <a href="subject.html#1519">[ subject ]</a> + <a href="author.html#1519">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001520.html b/zarb-ml/mageia-dev/20101129/001520.html new file mode 100644 index 000000000..647e65a32 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001520.html @@ -0,0 +1,97 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129192504.GJ21938%40mars-attacks.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001519.html"> + <LINK REL="Next" HREF="001522.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>nicolas vigier</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129192504.GJ21938%40mars-attacks.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">boklm at mars-attacks.org + </A><BR> + <I>Mon Nov 29 20:25:04 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001519.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001522.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1520">[ date ]</a> + <a href="thread.html#1520">[ thread ]</a> + <a href="subject.html#1520">[ subject ]</a> + <a href="author.html#1520">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Mon, 29 Nov 2010, andre999 wrote: + +><i> +</I>><i> The idea is not that the Mageia community would not support "extra" +</I>><i> packages. +</I>><i> It is just that if an "extra" package breaks, it shouldn't break a user's +</I>><i> system. +</I>><i> But if a "core" package breaks, we would expect that it would break many +</I>><i> users' systems. +</I>><i> Thus the priority to ensure that "core" packages are always fixed in a +</I>><i> timely manner. +</I> +I don't think we need repositories to define bug priorities. If a +package break the system, the bug report should mention it. And we can +also have minor bugs in "core" packages not breaking anything. Should +we fix them in a timely manner, before any critical bug on "extra" +packages breaking useful applications ? + +>><i> - Some packages can have a different support time. On Mandriva, "Base +</I>>><i> system& components" was supported longer, but it was not clear which +</I>>><i> packages were part of this. +</I>>><i> +</I>><i> Core is proposed to be largely "base system & components". Part of the +</I>><i> idea is to make clearer, to everyone, which packages have an enhanced level +</I>><i> of support. +</I>><i> Support time is another (useful) question. +</I> +Why do we need two repositories for that ? + +>><i> - Some packages have a lot of optional plugins, and we build them all, +</I>>><i> adding a lot of build requires. With main/contrib separation we need +</I>>><i> to add all the build dependencies to main, even if most of them are +</I>>><i> not runtime dependencies. +</I>>><i> +</I>><i> +</I>><i> We will have to be more selective for core packages, to avoid this problem. +</I>><i> Maybe "suggests", or other features being added with rpm5. +</I> +Suggests on BuildRequires does not exists. And we need them to be +installed for the build. + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001519.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001522.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1520">[ date ]</a> + <a href="thread.html#1520">[ thread ]</a> + <a href="subject.html#1520">[ subject ]</a> + <a href="author.html#1520">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001521.html b/zarb-ml/mageia-dev/20101129/001521.html new file mode 100644 index 000000000..f04593384 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001521.html @@ -0,0 +1,236 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF41367.4080709%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001516.html"> + <LINK REL="Next" HREF="001526.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF41367.4080709%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Mon Nov 29 21:56:07 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001526.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1521">[ date ]</a> + <a href="thread.html#1521">[ thread ]</a> + <a href="subject.html#1521">[ subject ]</a> + <a href="author.html#1521">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Samuel Verschelde a écrit : +><i> +</I>><i> Le lundi 29 novembre 2010 17:08:25, Michael Scherer a écrit : +</I>><i> +</I>>><i> Le lundi 29 novembre 2010 à 15:24 +0100, Samuel Verschelde a écrit : +</I>>><i> +</I>>>><i> Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit : +</I>>>><i> +</I>>>>><i> - complexity on the users system as they need to have twice the number +</I>>>>><i> of media to cope with this. This also appear in the interface of +</I>>>>><i> various tools, and it is imho uneeded. Most people will say that we +</I>>>>><i> already have too much medias. +</I>>>>><i> +</I>4 instead of 3 is 33% more. +That aside, you're essentially referring to package installer tools +(rpmdrake) for the user. +If we have a separate "extra", and the user chooses to (usually) only +install officially supported packages, the response to the user will be +faster with the extra media, not slower. +Now I deactivate contrib most of the time for faster performance. (It +makes a *big* difference.) +With a relatively smaller "core" (than "main"), we will have an even +greater performance advantage for keeping an extra set of media. +And if the user chooses to keep "extra" activated ? Essentially no +difference. + +But you do raise an important point. We do need to improve rpmdrake and +associated tools. +I think that that should be a priority. +However as long as the user is permitted to choose, they will be +presented with choices, in one form or another. Isn't choice part of +what Linux is supposed to be about ? +>>><i> Indeed, however it helps showing that there's a set of packages which is supported, +</I>>>><i> and another one which is only on behalf of the maintainer. In a community driven +</I>>>><i> distribution, this distinction may remains valid : some packages are officially +</I>>>><i> supported by the distribution, others may or may not be, depending on the maintainer +</I>>>><i> (or lack of maintainer). +</I>>>><i> +</I>Exactly +>><i> If there is a maintainer and he has a account, then it is a official +</I>>><i> one, and so the package is officially supported. That's all. There is no +</I>>><i> separation of "the organisation" and "the maintainers", we are not +</I>>><i> Mandriva. +</I>>><i> +</I>>><i> So either the package is supported, and we keep, or it is not, and then +</I>>><i> why should we keep it ? +</I>>><i> +</I>><i> Because it works, at least partially. Because it has users. It may have flaws, it may not have the latest security fixes, it may just be supported but only updated once a year... That's not a reason for dropping it. That's why distiction between officially supported and not officially supported is useful. There are working packages, seldom updated, which don't deserve to be dropped, but which can't be advertised as officially supported, and that's understandable. The world is not either black or white, there are many shades of grey, and that's particularly true for packages in a linux distribution. +</I>><i> +</I>><i> According to what you said, it looks like there will be only 2 kinds of packages : +</I>><i> - in the distribution (which would be equal to "supported") +</I>><i> - not in the distribution +</I>><i> +</I>><i> But we all know that there will be : +</I>><i> - supported, both in cauldron and stable releases (updates + backports) +</I>><i> - supported, both in cauldron and stable releases (updates, no backports) +</I>><i> - supported, in cauldron only : the maintainer only cares about cauldron and hasn't enough time to fix bugs in (to his mind) old stable releases +</I>><i> - the same, but some people do backports from time to time +</I>><i> - supported in stable releases, but dropped from the cauldron because the maintainer couldn't maintain it anymore +</I>><i> - has no maintainer, but works, although it may have bugs and security flaws. Has users. +</I>><i> - many other situations +</I>><i> - not in the distribution +</I>><i> +</I>><i> What I'm asking for is that we put dedicated work into ensuring packages flagged as supported have security and bugfix updates in stable releases. +</I>><i> +</I>><i> +</I>><i> In Mandriva, you can find many examples of packages in main which are not supported in reality, or even maybe simply don't work. You can find also many packages in contrib which are perfectly supported, in cooker as in stable releases. You gave me examples. However I see very rarely security or bugfix updates for packages in contrib for stable releases (or sometimes they go to backports), whereas there are many security fixes and bugfixes for packages in main thanks to Mandriva's security team. There really is a difference between supported packages and other, although it's far from perfect. +</I>><i> +</I>><i> If there's no difference in term of security updates between php and a random maintained game, then I won't be very confident in the distribution's quality. +</I>><i> +</I>><i> Let's say I want to install php on the stable Mageia 2011, will it be supported for security fixes and bugfixes ? For how long ? Are security fixes applied as soon as possible ? If the only answer is "is has a maintainer, so it should be supported like all the other packages", I'll probably avoid Mageia on a server. +</I>><i> +</I>><i> So this time it's not a rhetorical question : is Mageia willing to provide official support for a subset of the available packages ? +</I>><i> +</I>><i> Flagging some packages as officially supported is a matter of putting dedicated resources and processes to ensure - as much as possible - good quality for those package. Like I said before, having a maintainer in itself is not sufficient, we also need support policies and a list of officially supported packages. +</I>><i> +</I>Totally agree. +><i> +</I>><i> I agreed that the mirror structure is not the best way to make this distinction. An external list is good enough for that and can even bring new possibilities, as Nicolas Vigier stated in another post. +</I>><i> +</I> +I think that one advantage of using the mirror structure is that it is a +sandbox that makes it clear to everyone (packagers, maintainers, current +and potential users, qa, etc) what is officially supported and what is not. +It has largely worked for Mandriva. +What didn't work is +(1) the lack of a well-defined and applied criteria for what is to be +officially supported, and +(2) the lack of a clear applied policy and strategies of how to deal +with possible dependancies of supported packages on non-supported packages. + +Without this sandbox, packagers are much less likely to do what is +necessary to ensure that supported packages are fully supported, +including dependancies. Including getting the necessary support from +others to achieve this. +Support is much more than an official maintainer. + +The supposed advantages of discarding a set of repositories over having +an obvious sandbox aren't clear. +Another mechanism allowing the end-user to select only supported +packages will be at least as complex. +There will be no difference for mirrors. (Same size, just a few extra +directories.) +Packagers can't help but notice if accessing dependancies outside the +sandbox. + +Of course, if we can find another mechanism as likely to succeed ... +><i> ... +</I>><i> +</I>>><i> Well, everything should be supported or dropped, that's all. Easy, done +</I>>><i> by every other distros out there except those that place a artificial +</I>>><i> separation. If there is a security bug opened and no one act on it after +</I>>><i> a time, let's drop the package. If there is a severe bug and no one act, +</I>>><i> the same, let's drop it. +</I>>><i> +</I>>><i> If people want to resurrect a rpm, they can, there is a svn for that. +</I>>><i> +</I>><i> This is the most terrible thing I read so far. +</I>Sounds like a distro killer policy. But we're just getting started ... :( + +><i> I already tried to answer it earlier in this message, however here's a last example : +</I>><i> - Someone checks if postgresql is supported because if not he'll use another distribution where it is +</I>><i> - It is (because every package is supported, or it's dropped), but the poor user doesn't know that Nanar went away doing his own fork, no one stepped in to maintain it ! +</I>><i> - One year later, postgresql has still security bugs opened, no one takes care => package is dropped +</I>><i> +</I>><i> Now if there were a list of supported packages, either it would not be officially supported and the user would know he could use it but maybe won't have security and bugfix updates, or it is officially supported. Now take the example above : +</I>><i> - Someone checks if postgresql is supported because if not he'll use another distribution where it is +</I>><i> - It is ! +</I>><i> - However the maintainer went away doing his own fork, so he dropped maintainership. +</I>><i> - Someone in QA Team rings a bell : "this supported package isn't supported anymore, but we promised we would support it for Mageia 2011 for 2 years from now ! We have to do something !" +</I>><i> - The package team leader, or someone else, relays the warning and finds someone else to maintain the package, at least for Mageia 2011, for security and bugfix updates. +</I>><i> - (another scenario : there is a maintainer, but the package has pending issues for a long time, so we have to contact the maintainer about it, and maybe find another maintainer) +</I>><i> +</I>><i> The difference is : because we said we would support it for Mageia 2011's lifetime, we do everything possible to keep this promise, and I think we can succeed provided the set of supported packages is carefully done. Things will be clearer, to my mind. +</I>><i> +</I>Excellent example. +This also points to the advantage of a mirror-based categorization. +Support should only change by release, not stop somewhere in between. +Maybe caudron uses a list, which could change at any time (in view of +the next release), but users would never expect support to cease +mid-release. +>><i> We _already_ do not know what is supported or not at Mandriva. People +</I>>><i> push update to contribs ( I do push them for tor or puppet ), while some +</I>>><i> packages in main are not updated or buggy or simply unrebuildable ( see +</I>>><i> all mdk rpm still in the distro for long forgotten reasons ). See this +</I>>><i> old long standing pdftk bug caused by a issue in the java stack in +</I>>><i> main : <A HREF="https://qa.mandriva.com/show_bug.cgi?id=44372">https://qa.mandriva.com/show_bug.cgi?id=44372</A> . In main, and no +</I>>><i> one did anything. +</I>>><i> +</I>><i> Having packages which ought to be supported and are not in practice doesn't mean that there must be no difference between officially supported and not officially supported. +</I>><i> +</I>Exactly +>><i> There is also lots of duplication : +</I>>><i> - apache& nginx, who was moved to main likely because oden like nginx, +</I>>><i> - the various ftp servers, +</I>>><i> - sendmail& postfix, +</I>>><i> - the 4 tls/ssl implementation, +</I>>><i> - the 2 html rendering library ( webkit, gecko ) with more than 1 +</I>>><i> browser. +</I>>><i> +</I>><i> What prevents from refining the list if it's too big ? Choosing officially supported packages is a matter of setting priorities, because we have limited resources. In what way will things be better if there is no list of officially supported packages ? +</I>><i> +</I>Having 2 officially supported equivalents is not necessarily a bad idea +for important functions, as it gives more user choice - like mysql & +postgresql, or webkit & gecko. +However we don't need 47 packages that do almost exactly the same +thing. At least not officially supported. We do have to be selective. +Note that many packages, such as translation aides, alternate text +editors, etc, won't break a user's system if they break. So they would +belong in "extra" in any case. +><i> Regards +</I>><i> +</I>><i> Samuel Verschelde +</I>><i> +</I> +another 2 cents :) + +- André +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001526.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1521">[ date ]</a> + <a href="thread.html#1521">[ thread ]</a> + <a href="subject.html#1521">[ subject ]</a> + <a href="author.html#1521">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001522.html b/zarb-ml/mageia-dev/20101129/001522.html new file mode 100644 index 000000000..625b736c9 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001522.html @@ -0,0 +1,150 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF41BCE.60606%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001520.html"> + <LINK REL="Next" HREF="001525.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF41BCE.60606%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Mon Nov 29 22:31:58 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001520.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1522">[ date ]</a> + <a href="thread.html#1522">[ thread ]</a> + <a href="subject.html#1522">[ subject ]</a> + <a href="author.html#1522">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>nicolas vigier a écrit : +><i> On Mon, 29 Nov 2010, andre999 wrote: +</I>><i> +</I>><i> +</I>>><i> The idea is not that the Mageia community would not support "extra" +</I>>><i> packages. +</I>>><i> It is just that if an "extra" package breaks, it shouldn't break a user's +</I>>><i> system. +</I>>><i> But if a "core" package breaks, we would expect that it would break many +</I>>><i> users' systems. +</I>>><i> Thus the priority to ensure that "core" packages are always fixed in a +</I>>><i> timely manner. +</I>>><i> +</I>><i> I don't think we need repositories to define bug priorities. If a +</I>><i> package break the system, the bug report should mention it. And we can +</I>><i> also have minor bugs in "core" packages not breaking anything. Should +</I>><i> we fix them in a timely manner, before any critical bug on "extra" +</I>><i> packages breaking useful applications ? +</I>><i> +</I>I agree that minor bugs in core need not have absolute priority. +But from what I see, few bug reports mention that something "breaks the +system". +They focus on the issue in question, to varying degrees of success. +(Reminds me of end-user support. Much of the time they don't recognize +the real problem.) +My point is, significant bugs in core packages should be fixed in a +timely manner, as much as possible. And indeed, critical bugs should be +fixed. But if a critical bug affects a non-core package, it is likely +to affect only that package. Not so a core bug. + +By core, I mean in the logical sense. +If that can be done effectively and efficiently with a set of "core" +repositories, so be it. +However I don't see such a solution. +I would very much prefer to continue with the present separation until +such a solution, if any, is found. +And the cost of separate "core" and "extra" repositories is minimal, +assuming that core packages are officially supported. And separate +repositories do provide benefits to end-users, as well. +>>><i> - Some packages can have a different support time. On Mandriva, "Base +</I>>>><i> system& components" was supported longer, but it was not clear which +</I>>>><i> packages were part of this. +</I>>>><i> +</I>>>><i> +</I>>><i> Core is proposed to be largely "base system& components". Part of the +</I>>><i> idea is to make clearer, to everyone, which packages have an enhanced level +</I>>><i> of support. +</I>>><i> Support time is another (useful) question. +</I>>><i> +</I>><i> Why do we need two repositories for that ? +</I>><i> +</I>Sandbox. +It is clearer to everyone. +The fact that Mandriva didn't control what went into main is a large +part of their problem. +If you can find another solution, just as reliable, great. +But I suspect it would be more complex, and probably cost more in +resources as well. +The cost of extra repositories is almost nil - if we assume that we want +to rigorously control what is to be fully supported, and apply it. +>>><i> - Some packages have a lot of optional plugins, and we build them all, +</I>>>><i> adding a lot of build requires. With main/contrib separation we need +</I>>>><i> to add all the build dependencies to main, even if most of them are +</I>>>><i> not runtime dependencies. +</I>>>><i> +</I>>><i> We will have to be more selective for core packages, to avoid this problem. +</I>>><i> Maybe "suggests", or other features being added with rpm5. +</I>>><i> +</I>><i> Suggests on BuildRequires does not exists. And we need them to be +</I>><i> installed for the build. +</I>><i> +</I>If a core package has real buildrequires, then these requires should be +in core. +If only a non-core package has buildrequires, these requires need not +necessarily be in core. +Although packages like cmake should probably be in core anyway, as they +are very likely to be used to build packages. +I don't know details for rpm5, but it could have the equivalent of +suggests for buildrequires. (Like an alternate list of tools required ?) +Alternately, maybe some modification will have to be done to the spec files. +Since Mandriva is going through a very similar process, we could +probably share much of the changes required. + +By the way, for the conversion to Mageia, I would suggest assuming that +all of main + contrib is in extra, and moving those to core which meet +our criteria. +Much of main will be very quickly moved, such as base Linux/Gnu +packages, drak* tools, etc. +And selected applications like Go-oo/LibreOffice and Firefox. +We will first have to detail our criteria, of course. + +another 2 cents :) + +- André +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001520.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1522">[ date ]</a> + <a href="thread.html#1522">[ thread ]</a> + <a href="subject.html#1522">[ subject ]</a> + <a href="author.html#1522">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001523.html b/zarb-ml/mageia-dev/20101129/001523.html new file mode 100644 index 000000000..f5c648096 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001523.html @@ -0,0 +1,96 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF41D24.4000109%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001502.html"> + <LINK REL="Next" HREF="001504.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF41D24.4000109%40laposte.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">andr55 at laposte.net + </A><BR> + <I>Mon Nov 29 22:37:40 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001502.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001504.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1523">[ date ]</a> + <a href="thread.html#1523">[ thread ]</a> + <a href="subject.html#1523">[ subject ]</a> + <a href="author.html#1523">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>nicolas vigier a écrit : +><i> On Sat, 27 Nov 2010, Thomas Backlund wrote: +</I>><i> +</I>><i> +</I>>><i> Wolfgang Bornath skrev 27.11.2010 10:03: +</I>>><i> +</I>>>><i> 2010/11/27 Ahmad Samir<<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">ahmadsamir3891 at gmail.com</A>>: +</I>>>><i> +</I>>>>><i> IMHO, the mirrorlist in its current status should be dropped +</I>>>>><i> altogether... it's only good if the user has good mirrors near where +</I>>>>><i> he lives, otherwise it just fails miserably. The whole point of using +</I>>>>><i> a mirrorlist was that "urpmi will switch to another mirror if the +</I>>>>><i> currently used one fails / can't be reached", that switch doesn't +</I>>>>><i> happen, ("md5sum mismatch" rings a bell?). +</I>>>>><i> +</I>>>><i> Although I am a friend of SmartUrpmi and EasyUrpmi I do understand the +</I>>>><i> easy way the mirrorlist system provides, especially for new users. The +</I>>>><i> failure of this system due to failing mirrors was already discussed at +</I>>>><i> Mandriva and there is a bug in MDv bugzilla about it - still open. +</I>>>><i> +</I>>>><i> But even if this bug could be fixed, the option for mirror maintainers +</I>>>><i> to exclude parts of the official mirror structure puts the mirrorlist +</I>>>><i> system in jeopardy, unless we have 2 mirrorlists, one with and one +</I>>>><i> without "problematic" software and let the user select one or the +</I>>>><i> other before he sets up his media. +</I>>>><i> +</I>>>><i> +</I>>><i> This is actually an option I thought of... +</I>>><i> +</I>>><i> Providing two mirror list, one list with "free" mirrors and one with "full" +</I>>><i> mirrors. +</I>>><i> +</I>><i> Or one list, but listing all medias individually. +</I>><i> +</I> +One list provides a lot more flexibility, particularly in defining what +we want mirrors to carry. We could end up with several types of mirrors. +Some ISO-only, others all but ISOs, etc. + +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001502.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001504.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1523">[ date ]</a> + <a href="thread.html#1523">[ thread ]</a> + <a href="subject.html#1523">[ subject ]</a> + <a href="author.html#1523">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001524.html b/zarb-ml/mageia-dev/20101129/001524.html new file mode 100644 index 000000000..175191af1 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001524.html @@ -0,0 +1,83 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF421C7.7080908%40zamiz.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001508.html"> + + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>Yann Ciret</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF421C7.7080908%40zamiz.net%3E" + TITLE="[Mageia-dev] Mirror layout, round two">mageia at zamiz.net + </A><BR> + <I>Mon Nov 29 22:57:27 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001508.html">[Mageia-dev] Mirror layout, round two +</A></li> + + <LI> <B>Messages sorted by:</B> + <a href="date.html#1524">[ date ]</a> + <a href="thread.html#1524">[ thread ]</a> + <a href="subject.html#1524">[ subject ]</a> + <a href="author.html#1524">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le 29/11/2010 15:44, Dexter Morgan a écrit : +><i> On Mon, Nov 29, 2010 at 3:10 PM, Jerome Quelin <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">jquelin at gmail.com</A>> wrote: +</I>>><i> On 10/11/28 22:12 +0200, Thomas Backlund wrote: +</I>>>><i> So the mirror medias accordingly to all comments so far would be a simple: +</I>>>><i> +</I>>>><i> * core +</I>>>><i> - enabled by default +</I>>>><i> - mirrors must mirror this media to be listed as a mirror +</I>>>><i> - only GPL stuff +</I>>>><i> - must be selfcontained +</I>><i> +</I>><i> I liked the main/contrib separation. +</I>><i> Main was officially supported + sec updates and with only core this +</I>><i> means a lot more work/support. +</I>><i> +</I>I dislike the main/contrib separation in some case. +The first example is with Mozilla Thunderbird packages. Some extension +packages are in contrib. So each time thunderbird received security +update, the update cannot be installed because of non automatically +rebuild of his contrib package. And each time I see a bug report of user +asking a manual rebuilt. With only one core media, this situation will +disapear (I hope). + +><i> +</I>><i> the other part ( non free + tainted ) seems OK for me +</I>><i> +</I>Me too + +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001508.html">[Mageia-dev] Mirror layout, round two +</A></li> + + <LI> <B>Messages sorted by:</B> + <a href="date.html#1524">[ date ]</a> + <a href="thread.html#1524">[ thread ]</a> + <a href="subject.html#1524">[ subject ]</a> + <a href="author.html#1524">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001525.html b/zarb-ml/mageia-dev/20101129/001525.html new file mode 100644 index 000000000..03fe5e770 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001525.html @@ -0,0 +1,126 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129222020.GK21938%40mars-attacks.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001522.html"> + <LINK REL="Next" HREF="001510.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>nicolas vigier</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129222020.GK21938%40mars-attacks.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">boklm at mars-attacks.org + </A><BR> + <I>Mon Nov 29 23:20:20 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001522.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001510.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1525">[ date ]</a> + <a href="thread.html#1525">[ thread ]</a> + <a href="subject.html#1525">[ subject ]</a> + <a href="author.html#1525">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Mon, 29 Nov 2010, andre999 wrote: + +><i> They focus on the issue in question, to varying degrees of success. +</I>><i> (Reminds me of end-user support. Much of the time they don't recognize the +</I>><i> real problem.) +</I>><i> My point is, significant bugs in core packages should be fixed in a timely +</I>><i> manner, as much as possible. And indeed, critical bugs should be fixed. +</I>><i> But if a critical bug affects a non-core package, it is likely to affect +</I>><i> only that package. Not so a core bug. +</I> +I would expect package maintainers to know wether the packages they +maintain are critical or not by themself. I don't think it would make +sense to look at the repository name to decide if it's a critical bug or +not. + +>>><i> Core is proposed to be largely "base system& components". Part of the +</I>>>><i> idea is to make clearer, to everyone, which packages have an enhanced level +</I>>>><i> of support. +</I>>>><i> Support time is another (useful) question. +</I>>>><i> +</I>>><i> Why do we need two repositories for that ? +</I>>><i> +</I>><i> Sandbox. +</I>><i> It is clearer to everyone. +</I> +How is that "clearer" ? The level of support is not even displayed in +current versions of rpmdrake. And you have to click on "Details" to see +the repository name. +If we provide the list of fully supported packages separatly, we could +display the level of support in the package manager. How would that be +"less clear to everyone" ? + +><i> The fact that Mandriva didn't control what went into main is a large part +</I>><i> of their problem. +</I> +Mandriva controled what went into main. + +><i> If you can find another solution, just as reliable, great. +</I>><i> But I suspect it would be more complex, and probably cost more in resources +</I>><i> as well. +</I>><i> The cost of extra repositories is almost nil - if we assume that we want to +</I>><i> rigorously control what is to be fully supported, and apply it. +</I> +As already explained in this thread, the cost is not nil, and we don't +need repositories to define what is fully supported. + +>>>><i> - Some packages have a lot of optional plugins, and we build them all, +</I>>>>><i> adding a lot of build requires. With main/contrib separation we need +</I>>>>><i> to add all the build dependencies to main, even if most of them are +</I>>>>><i> not runtime dependencies. +</I>>>>><i> +</I>>>><i> We will have to be more selective for core packages, to avoid this problem. +</I>>>><i> Maybe "suggests", or other features being added with rpm5. +</I>>>><i> +</I>>><i> Suggests on BuildRequires does not exists. And we need them to be +</I>>><i> installed for the build. +</I>>><i> +</I>><i> If a core package has real buildrequires, then these requires should be in +</I>><i> core. +</I> +What is "real buildrequires" ? + +><i> If only a non-core package has buildrequires, these requires need not +</I>><i> necessarily be in core. +</I>><i> Although packages like cmake should probably be in core anyway, as they are +</I>><i> very likely to be used to build packages. +</I>><i> I don't know details for rpm5, but it could have the equivalent of suggests +</I>><i> for buildrequires. (Like an alternate list of tools required ?) +</I> +Suggests for buildrequires doesn't make much sense. + +</PRE> + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001522.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001510.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1525">[ date ]</a> + <a href="thread.html#1525">[ thread ]</a> + <a href="subject.html#1525">[ subject ]</a> + <a href="author.html#1525">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/001526.html b/zarb-ml/mageia-dev/20101129/001526.html new file mode 100644 index 000000000..f745f5775 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001526.html @@ -0,0 +1,69 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Mirror layout, round two + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129223949.GL21938%40mars-attacks.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="001521.html"> + <LINK REL="Next" HREF="001498.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Mirror layout, round two</H1> + <B>nicolas vigier</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C20101129223949.GL21938%40mars-attacks.org%3E" + TITLE="[Mageia-dev] Mirror layout, round two">boklm at mars-attacks.org + </A><BR> + <I>Mon Nov 29 23:39:49 CET 2010</I> + <P><UL> + <LI>Previous message: <A HREF="001521.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001498.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1526">[ date ]</a> + <a href="thread.html#1526">[ thread ]</a> + <a href="subject.html#1526">[ subject ]</a> + <a href="author.html#1526">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Mon, 29 Nov 2010, andre999 wrote: + +><i> +</I>><i> The supposed advantages of discarding a set of repositories over having an +</I>><i> obvious sandbox aren't clear. +</I> +I think misc already explained it clearly in this mail : +<A HREF="https://www.mageia.org/pipermail/mageia-dev/20101129/001503.html">https://www.mageia.org/pipermail/mageia-dev/20101129/001503.html</A> + +If you disagree, you can reply to his email. But don't keep repeating +that there's not clear drawbacks, that the cost of creating new +repositories is almost nil and this kind of thing if you don't have +any real arguments. + +</PRE> + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="001521.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI>Next message: <A HREF="001498.html">[Mageia-dev] Mirror layout, round two +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#1526">[ date ]</a> + <a href="thread.html#1526">[ thread ]</a> + <a href="subject.html#1526">[ subject ]</a> + <a href="author.html#1526">[ 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> diff --git a/zarb-ml/mageia-dev/20101129/author.html b/zarb-ml/mageia-dev/20101129/author.html new file mode 100644 index 000000000..19d4efdf6 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/author.html @@ -0,0 +1,287 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <title>The Mageia-dev 29 November 2010 Archive by author</title> + <META NAME="robots" CONTENT="noindex,follow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <a name="start"></A> + <h1>29 November 2010 Archives by author</h1> + <ul> + <li> <b>Messages sorted by:</b> + <a href="thread.html#start">[ thread ]</a> + <a href="subject.html#start">[ subject ]</a> + + <a href="date.html#start">[ date ]</a> + + <li><b><a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More info on this list... + </a></b></li> + </ul> + <p><b>Starting:</b> <i>Mon Nov 29 01:24:42 CET 2010</i><br> + <b>Ending:</b> <i>Mon Nov 29 23:39:49 CET 2010</i><br> + <b>Messages:</b> 48<p> + <ul> + +<LI><A HREF="001491.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1491"> </A> +<I>Thomas Backlund +</I> + +<LI><A HREF="001524.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1524"> </A> +<I>Yann Ciret +</I> + +<LI><A HREF="001483.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1483"> </A> +<I>Hoyt Duff +</I> + +<LI><A HREF="001505.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1505"> </A> +<I>Kira +</I> + +<LI><A HREF="001518.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1518"> </A> +<I>Renaud MICHEL +</I> + +<LI><A HREF="001508.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1508"> </A> +<I>Dexter Morgan +</I> + +<LI><A HREF="001504.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1504"> </A> +<I>Jerome Quelin +</I> + +<LI><A HREF="001481.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1481"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001487.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1487"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001488.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1488"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001503.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1503"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001510.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1510"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001480.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1480"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001482.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1482"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001489.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1489"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001490.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1490"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001500.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1500"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001512.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1512"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001514.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1514"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1484"> </A> +<I>Maarten Vanraes +</I> + +<LI><A HREF="001485.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1485"> </A> +<I>Maarten Vanraes +</I> + +<LI><A HREF="001486.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1486"> </A> +<I>Maarten Vanraes +</I> + +<LI><A HREF="001496.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1496"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001497.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1497"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001498.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1498"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001499.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1499"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001506.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1506"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001507.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1507"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001511.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1511"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001513.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1513"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001515.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1515"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1516"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001492.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1492"> </A> +<I>andre999 +</I> + +<LI><A HREF="001493.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1493"> </A> +<I>andre999 +</I> + +<LI><A HREF="001494.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1494"> </A> +<I>andre999 +</I> + +<LI><A HREF="001495.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1495"> </A> +<I>andre999 +</I> + +<LI><A HREF="001517.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1517"> </A> +<I>andre999 +</I> + +<LI><A HREF="001519.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1519"> </A> +<I>andre999 +</I> + +<LI><A HREF="001521.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1521"> </A> +<I>andre999 +</I> + +<LI><A HREF="001522.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1522"> </A> +<I>andre999 +</I> + +<LI><A HREF="001523.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1523"> </A> +<I>andre999 +</I> + +<LI><A HREF="001479.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1479"> </A> +<I>Michael scherer +</I> + +<LI><A HREF="001501.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1501"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001502.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1502"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001509.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1509"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001520.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1520"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1525"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001526.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1526"> </A> +<I>nicolas vigier +</I> + + </ul> + <p> + <a name="end"><b>Last message date:</b></a> + <i>Mon Nov 29 23:39:49 CET 2010</i><br> + <b>Archived on:</b> <i>Mon Nov 29 23:39:54 CET 2010</i> + <p> + <ul> + <li> <b>Messages sorted by:</b> + <a href="thread.html#start">[ thread ]</a> + <a href="subject.html#start">[ subject ]</a> + + <a href="date.html#start">[ date ]</a> + <li><b><a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More info on this list... + </a></b></li> + </ul> + <p> + <hr> + <i>This archive was generated by + Pipermail 0.09 (Mailman edition).</i> + </BODY> +</HTML> + diff --git a/zarb-ml/mageia-dev/20101129/date.html b/zarb-ml/mageia-dev/20101129/date.html new file mode 100644 index 000000000..575a5b392 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/date.html @@ -0,0 +1,287 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <title>The Mageia-dev 29 November 2010 Archive by date</title> + <META NAME="robots" CONTENT="noindex,follow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <a name="start"></A> + <h1>29 November 2010 Archives by date</h1> + <ul> + <li> <b>Messages sorted by:</b> + <a href="thread.html#start">[ thread ]</a> + <a href="subject.html#start">[ subject ]</a> + <a href="author.html#start">[ author ]</a> + + + <li><b><a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More info on this list... + </a></b></li> + </ul> + <p><b>Starting:</b> <i>Mon Nov 29 01:24:42 CET 2010</i><br> + <b>Ending:</b> <i>Mon Nov 29 23:39:49 CET 2010</i><br> + <b>Messages:</b> 48<p> + <ul> + +<LI><A HREF="001479.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1479"> </A> +<I>Michael scherer +</I> + +<LI><A HREF="001480.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1480"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001481.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1481"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001482.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1482"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001483.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1483"> </A> +<I>Hoyt Duff +</I> + +<LI><A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1484"> </A> +<I>Maarten Vanraes +</I> + +<LI><A HREF="001485.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1485"> </A> +<I>Maarten Vanraes +</I> + +<LI><A HREF="001486.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1486"> </A> +<I>Maarten Vanraes +</I> + +<LI><A HREF="001487.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1487"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001488.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1488"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001489.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1489"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001490.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1490"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001491.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1491"> </A> +<I>Thomas Backlund +</I> + +<LI><A HREF="001492.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1492"> </A> +<I>andre999 +</I> + +<LI><A HREF="001493.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1493"> </A> +<I>andre999 +</I> + +<LI><A HREF="001494.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1494"> </A> +<I>andre999 +</I> + +<LI><A HREF="001496.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1496"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001495.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1495"> </A> +<I>andre999 +</I> + +<LI><A HREF="001497.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1497"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001498.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1498"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001499.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1499"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001500.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1500"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001501.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1501"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001502.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1502"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001503.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1503"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001504.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1504"> </A> +<I>Jerome Quelin +</I> + +<LI><A HREF="001505.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1505"> </A> +<I>Kira +</I> + +<LI><A HREF="001506.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1506"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001507.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1507"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001508.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1508"> </A> +<I>Dexter Morgan +</I> + +<LI><A HREF="001509.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1509"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001510.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1510"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001511.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1511"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001512.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1512"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001513.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1513"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001514.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1514"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001515.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1515"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1516"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001517.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1517"> </A> +<I>andre999 +</I> + +<LI><A HREF="001518.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1518"> </A> +<I>Renaud MICHEL +</I> + +<LI><A HREF="001519.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1519"> </A> +<I>andre999 +</I> + +<LI><A HREF="001520.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1520"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001521.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1521"> </A> +<I>andre999 +</I> + +<LI><A HREF="001522.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1522"> </A> +<I>andre999 +</I> + +<LI><A HREF="001523.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1523"> </A> +<I>andre999 +</I> + +<LI><A HREF="001524.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1524"> </A> +<I>Yann Ciret +</I> + +<LI><A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1525"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001526.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1526"> </A> +<I>nicolas vigier +</I> + + </ul> + <p> + <a name="end"><b>Last message date:</b></a> + <i>Mon Nov 29 23:39:49 CET 2010</i><br> + <b>Archived on:</b> <i>Mon Nov 29 23:39:54 CET 2010</i> + <p> + <ul> + <li> <b>Messages sorted by:</b> + <a href="thread.html#start">[ thread ]</a> + <a href="subject.html#start">[ subject ]</a> + <a href="author.html#start">[ author ]</a> + + <li><b><a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More info on this list... + </a></b></li> + </ul> + <p> + <hr> + <i>This archive was generated by + Pipermail 0.09 (Mailman edition).</i> + </BODY> +</HTML> + diff --git a/zarb-ml/mageia-dev/20101129/index.html b/zarb-ml/mageia-dev/20101129/index.html new file mode 120000 index 000000000..db4b46f72 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/index.html @@ -0,0 +1 @@ +thread.html
\ No newline at end of file diff --git a/zarb-ml/mageia-dev/20101129/subject.html b/zarb-ml/mageia-dev/20101129/subject.html new file mode 100644 index 000000000..d9fd9b082 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/subject.html @@ -0,0 +1,287 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <title>The Mageia-dev 29 November 2010 Archive by subject</title> + <META NAME="robots" CONTENT="noindex,follow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <a name="start"></A> + <h1>29 November 2010 Archives by subject</h1> + <ul> + <li> <b>Messages sorted by:</b> + <a href="thread.html#start">[ thread ]</a> + + <a href="author.html#start">[ author ]</a> + <a href="date.html#start">[ date ]</a> + + <li><b><a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More info on this list... + </a></b></li> + </ul> + <p><b>Starting:</b> <i>Mon Nov 29 01:24:42 CET 2010</i><br> + <b>Ending:</b> <i>Mon Nov 29 23:39:49 CET 2010</i><br> + <b>Messages:</b> 48<p> + <ul> + +<LI><A HREF="001479.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1479"> </A> +<I>Michael scherer +</I> + +<LI><A HREF="001480.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1480"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001481.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1481"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001482.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1482"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001483.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1483"> </A> +<I>Hoyt Duff +</I> + +<LI><A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1484"> </A> +<I>Maarten Vanraes +</I> + +<LI><A HREF="001485.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1485"> </A> +<I>Maarten Vanraes +</I> + +<LI><A HREF="001486.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1486"> </A> +<I>Maarten Vanraes +</I> + +<LI><A HREF="001487.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1487"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001488.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1488"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001489.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1489"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001490.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1490"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001491.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1491"> </A> +<I>Thomas Backlund +</I> + +<LI><A HREF="001492.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1492"> </A> +<I>andre999 +</I> + +<LI><A HREF="001493.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1493"> </A> +<I>andre999 +</I> + +<LI><A HREF="001494.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1494"> </A> +<I>andre999 +</I> + +<LI><A HREF="001496.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1496"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001495.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1495"> </A> +<I>andre999 +</I> + +<LI><A HREF="001497.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1497"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001498.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1498"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001499.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1499"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001500.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1500"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001501.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1501"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001502.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1502"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001503.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1503"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001504.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1504"> </A> +<I>Jerome Quelin +</I> + +<LI><A HREF="001505.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1505"> </A> +<I>Kira +</I> + +<LI><A HREF="001506.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1506"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001507.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1507"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001508.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1508"> </A> +<I>Dexter Morgan +</I> + +<LI><A HREF="001509.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1509"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001510.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1510"> </A> +<I>Michael Scherer +</I> + +<LI><A HREF="001511.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1511"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001512.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1512"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001513.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1513"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001514.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1514"> </A> +<I>Olivier Thauvin +</I> + +<LI><A HREF="001515.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1515"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1516"> </A> +<I>Samuel Verschelde +</I> + +<LI><A HREF="001517.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1517"> </A> +<I>andre999 +</I> + +<LI><A HREF="001518.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1518"> </A> +<I>Renaud MICHEL +</I> + +<LI><A HREF="001519.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1519"> </A> +<I>andre999 +</I> + +<LI><A HREF="001520.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1520"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001521.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1521"> </A> +<I>andre999 +</I> + +<LI><A HREF="001522.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1522"> </A> +<I>andre999 +</I> + +<LI><A HREF="001523.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1523"> </A> +<I>andre999 +</I> + +<LI><A HREF="001524.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1524"> </A> +<I>Yann Ciret +</I> + +<LI><A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1525"> </A> +<I>nicolas vigier +</I> + +<LI><A HREF="001526.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1526"> </A> +<I>nicolas vigier +</I> + + </ul> + <p> + <a name="end"><b>Last message date:</b></a> + <i>Mon Nov 29 23:39:49 CET 2010</i><br> + <b>Archived on:</b> <i>Mon Nov 29 23:39:54 CET 2010</i> + <p> + <ul> + <li> <b>Messages sorted by:</b> + <a href="thread.html#start">[ thread ]</a> + + <a href="author.html#start">[ author ]</a> + <a href="date.html#start">[ date ]</a> + <li><b><a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More info on this list... + </a></b></li> + </ul> + <p> + <hr> + <i>This archive was generated by + Pipermail 0.09 (Mailman edition).</i> + </BODY> +</HTML> + diff --git a/zarb-ml/mageia-dev/20101129/thread.html b/zarb-ml/mageia-dev/20101129/thread.html new file mode 100644 index 000000000..3f7ba40f2 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/thread.html @@ -0,0 +1,365 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <title>The Mageia-dev 29 November 2010 Archive by thread</title> + <META NAME="robots" CONTENT="noindex,follow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <a name="start"></A> + <h1>29 November 2010 Archives by thread</h1> + <ul> + <li> <b>Messages sorted by:</b> + + <a href="subject.html#start">[ subject ]</a> + <a href="author.html#start">[ author ]</a> + <a href="date.html#start">[ date ]</a> + + <li><b><a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More info on this list... + </a></b></li> + </ul> + <p><b>Starting:</b> <i>Mon Nov 29 01:24:42 CET 2010</i><br> + <b>Ending:</b> <i>Mon Nov 29 23:39:49 CET 2010</i><br> + <b>Messages:</b> 48<p> + <ul> + +<!--0 01290990282- --> +<LI><A HREF="001479.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1479"> </A> +<I>Michael scherer +</I> + +<UL> +<!--1 01290990282-01290994409- --> +<LI><A HREF="001484.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1484"> </A> +<I>Maarten Vanraes +</I> + +<UL> +<!--2 01290990282-01290994409-01291000599- --> +<LI><A HREF="001488.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1488"> </A> +<I>Michael Scherer +</I> + +<!--2 01290990282-01290994409-01291001527- --> +<LI><A HREF="001489.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1489"> </A> +<I>Olivier Thauvin +</I> + +<UL> +<!--3 01290990282-01290994409-01291001527-01291030869- --> +<LI><A HREF="001496.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1496"> </A> +<I>Samuel Verschelde +</I> + +</UL> +</UL> +<!--1 01290990282-01291021795- --> +<LI><A HREF="001492.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1492"> </A> +<I>andre999 +</I> + +</UL> +<!--0 01290991535- --> +<LI><A HREF="001480.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1480"> </A> +<I>Olivier Thauvin +</I> + +<UL> +<!--1 01290991535-01291055145- --> +<LI><A HREF="001518.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1518"> </A> +<I>Renaud MICHEL +</I> + +</UL> +<!--0 01290991898- --> +<LI><A HREF="001481.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1481"> </A> +<I>Michael Scherer +</I> + +<UL> +<!--1 01290991898-01290994978- --> +<LI><A HREF="001486.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1486"> </A> +<I>Maarten Vanraes +</I> + +</UL> +<!--0 01290992773- --> +<LI><A HREF="001482.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1482"> </A> +<I>Olivier Thauvin +</I> + +<UL> +<!--1 01290992773-01290993976- --> +<LI><A HREF="001483.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1483"> </A> +<I>Hoyt Duff +</I> + +<UL> +<!--2 01290992773-01290993976-01290998029- --> +<LI><A HREF="001487.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1487"> </A> +<I>Michael Scherer +</I> + +</UL> +<!--1 01290992773-01290994796- --> +<LI><A HREF="001485.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1485"> </A> +<I>Maarten Vanraes +</I> + +<UL> +<!--2 01290992773-01290994796-01291002199- --> +<LI><A HREF="001490.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1490"> </A> +<I>Olivier Thauvin +</I> + +</UL> +<!--1 01290992773-01291017985- --> +<LI><A HREF="001491.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1491"> </A> +<I>Thomas Backlund +</I> + +<UL> +<!--2 01290992773-01291017985-01291037318- --> +<LI><A HREF="001500.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1500"> </A> +<I>Olivier Thauvin +</I> + +</UL> +</UL> +<!--0 01291024284- --> +<LI><A HREF="001493.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1493"> </A> +<I>andre999 +</I> + +<!--0 01291025477- --> +<LI><A HREF="001494.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1494"> </A> +<I>andre999 +</I> + +<!--0 01291031182- --> +<LI><A HREF="001495.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1495"> </A> +<I>andre999 +</I> + +<UL> +<!--1 01291031182-01291032848- --> +<LI><A HREF="001497.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1497"> </A> +<I>Samuel Verschelde +</I> + +<UL> +<!--2 01291031182-01291032848-01291038980- --> +<LI><A HREF="001503.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1503"> </A> +<I>Michael Scherer +</I> + +<UL> +<!--3 01291031182-01291032848-01291038980-01291040644- --> +<LI><A HREF="001506.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1506"> </A> +<I>Samuel Verschelde +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291041063- --> +<LI><A HREF="001507.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1507"> </A> +<I>Samuel Verschelde +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291041063-01291047068- --> +<LI><A HREF="001512.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1512"> </A> +<I>Olivier Thauvin +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291041063-01291047068-01291047339- --> +<LI><A HREF="001513.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1513"> </A> +<I>Samuel Verschelde +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291041063-01291047068-01291047339-01291047487- --> +<LI><A HREF="001514.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1514"> </A> +<I>Olivier Thauvin +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291041063-01291047068-01291047339-01291047487-01291049798- --> +<LI><A HREF="001515.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1515"> </A> +<I>Samuel Verschelde +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291041063-01291047068-01291047339-01291047487-01291049798-01291052899- --> +<LI><A HREF="001517.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1517"> </A> +<I>andre999 +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046556- --> +<LI><A HREF="001509.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1509"> </A> +<I>nicolas vigier +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046556-01291046934- --> +<LI><A HREF="001511.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1511"> </A> +<I>Samuel Verschelde +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046556-01291057059- --> +<LI><A HREF="001519.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1519"> </A> +<I>andre999 +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046556-01291057059-01291058704- --> +<LI><A HREF="001520.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1520"> </A> +<I>nicolas vigier +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046556-01291057059-01291058704-01291066318- --> +<LI><A HREF="001522.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1522"> </A> +<I>andre999 +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046556-01291057059-01291058704-01291066318-01291069220- --> +<LI><A HREF="001525.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1525"> </A> +<I>nicolas vigier +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046905- --> +<LI><A HREF="001510.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1510"> </A> +<I>Michael Scherer +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046905-01291051775- --> +<LI><A HREF="001516.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1516"> </A> +<I>Samuel Verschelde +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046905-01291051775-01291064167- --> +<LI><A HREF="001521.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1521"> </A> +<I>andre999 +</I> + +<!--3 01291031182-01291032848-01291038980-01291040644-01291046905-01291051775-01291064167-01291070389- --> +<LI><A HREF="001526.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1526"> </A> +<I>nicolas vigier +</I> + +</UL> +</UL> +</UL> +<!--0 01291033166- --> +<LI><A HREF="001498.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1498"> </A> +<I>Samuel Verschelde +</I> + +<!--0 01291033263- --> +<LI><A HREF="001499.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1499"> </A> +<I>Samuel Verschelde +</I> + +<!--0 01291038685- --> +<LI><A HREF="001501.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1501"> </A> +<I>nicolas vigier +</I> + +<!--0 01291038976- --> +<LI><A HREF="001502.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1502"> </A> +<I>nicolas vigier +</I> + +<UL> +<!--1 01291038976-01291066660- --> +<LI><A HREF="001523.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1523"> </A> +<I>andre999 +</I> + +</UL> +<!--0 01291039847- --> +<LI><A HREF="001504.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1504"> </A> +<I>Jerome Quelin +</I> + +<UL> +<!--1 01291039847-01291040458- --> +<LI><A HREF="001505.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1505"> </A> +<I>Kira +</I> + +<!--1 01291039847-01291041883- --> +<LI><A HREF="001508.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1508"> </A> +<I>Dexter Morgan +</I> + +<UL> +<!--2 01291039847-01291041883-01291067847- --> +<LI><A HREF="001524.html">[Mageia-dev] Mirror layout, round two +</A><A NAME="1524"> </A> +<I>Yann Ciret +</I> + +</UL> +</UL> + </ul> + <p> + <a name="end"><b>Last message date:</b></a> + <i>Mon Nov 29 23:39:49 CET 2010</i><br> + <b>Archived on:</b> <i>Mon Nov 29 23:39:54 CET 2010</i> + <p> + <ul> + <li> <b>Messages sorted by:</b> + + <a href="subject.html#start">[ subject ]</a> + <a href="author.html#start">[ author ]</a> + <a href="date.html#start">[ date ]</a> + <li><b><a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More info on this list... + </a></b></li> + </ul> + <p> + <hr> + <i>This archive was generated by + Pipermail 0.09 (Mailman edition).</i> + </BODY> +</HTML> + |