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