diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101129/001484.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101129/001484.html | 379 |
1 files changed, 379 insertions, 0 deletions
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> |