Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
2010/11/26 andre999 : > MIhail Papadopoulos a écrit : >> >> >> Why not going down the right path: A rolling release cycle would be simply >> great. After all, this isn't a commercial distribution, so it shouldn't be >> a total noob Ubuntu-style mishmash. >> > > Why ? > What do you mean by "rolling" ? > How would it improve things for the user ? > How would it improve things for the developers/packages/translators who > provide Mageia ? > What are the costs ? > What are the benefits ? > And how does that compare with the alternatives ? This has already been discussed in length in one of the lists, very early, IIRC ist was early October . There were even polls in communities about. -- wobo
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le 2010-11-26 03:14, Wolfgang Bornath a écrit : 2010/11/26 andre999: MIhail Papadopoulos a écrit : Why not going down the right path: A rolling release cycle would be simply great. After all, this isn't a commercial distribution, so it shouldn't be a total noob Ubuntu-style mishmash. Why ? What do you mean by "rolling" ? How would it improve things for the user ? How would it improve things for the developers/packages/translators who provide Mageia ? What are the costs ? What are the benefits ? And how does that compare with the alternatives ? This has already been discussed in length in one of the lists, very early, IIRC ist was early October . There were even polls in communities about. Yes it was. I think it will re-surface again due to Ubuntu's recent advertising of going to a "rolling distro" scheme. We may have to go through another round of these comments. Do we have an archive list of the user mailist where we can refer people to continue on that particular thread? Are the mailists archived? Marc Marketing Team Member
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Marc Paré schrieb am 2010-11-26 > Do we have an archive list of the user mailist where we can refer people > to continue on that particular thread? Are the mailists archived? https://www.mageia.org/pipermail/mageia-dev/20101009/001055.html -- http://www.mageia.org - Mageia, the magic continues Oliver Burger Mageia webteam
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le 2010-11-26 05:35, Oliver Burger a écrit : Marc Paré schrieb am 2010-11-26 Do we have an archive list of the user mailist where we can refer people to continue on that particular thread? Are the mailists archived? https://www.mageia.org/pipermail/mageia-dev/20101009/001055.html Merci Olivier Marc
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
On 26 November 2010 12:21, Marc Paré wrote: > Le 2010-11-26 03:14, Wolfgang Bornath a écrit : >> >> 2010/11/26 andre999: >>> >>> MIhail Papadopoulos a écrit : Why not going down the right path: A rolling release cycle would be simply great. After all, this isn't a commercial distribution, so it shouldn't be a total noob Ubuntu-style mishmash. >>> >>> Why ? >>> What do you mean by "rolling" ? >>> How would it improve things for the user ? >>> How would it improve things for the developers/packages/translators who >>> provide Mageia ? >>> What are the costs ? >>> What are the benefits ? >>> And how does that compare with the alternatives ? >> >> This has already been discussed in length in one of the lists, very >> early, IIRC ist was early October . There were even polls in >> communities about. >> > > Yes it was. I think it will re-surface again due to Ubuntu's recent > advertising of going to a "rolling distro" scheme. We may have to go through > another round of these comments. > > Do we have an archive list of the user mailist where we can refer people to > continue on that particular thread? Are the mailists archived? > > Marc > Marketing Team Member > > You mean the "rumours" that Ubuntu will switch to a rolling distro model? http://www.h-online.com/open/news/item/Ubuntu-Rolling-release-rumours-wrong-1142040.html (thanks to misc posting the link on IRC yesterday). -- Ahmad Samir
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le 2010-11-26 06:23, Ahmad Samir a écrit : You mean the "rumours" that Ubuntu will switch to a rolling distro model? http://www.h-online.com/open/news/item/Ubuntu-Rolling-release-rumours-wrong-1142040.html (thanks to misc posting the link on IRC yesterday). Yes. Thanks for the link and setting me straight on this too. I'm sure that I am not the only one who was not fully informed of the reply to the original rumour. I read the original article on LinuxToday.com. I now see that they have a link to an article setting this straight http://www.networkworld.com/community/blog/ubuntu-sticking-six-month-development-cycle Thanks again. Cheers Marc
Re: [Mageia-dev] Release cycle - what is actually POSSIBLE?
Le vendredi 26 novembre 2010 à 06:49 -0500, Marc Paré a écrit : > Le 2010-11-26 06:23, Ahmad Samir a écrit : > > > > > You mean the "rumours" that Ubuntu will switch to a rolling distro > > model? > > http://www.h-online.com/open/news/item/Ubuntu-Rolling-release-rumours-wrong-1142040.html > > > > (thanks to misc posting the link on IRC yesterday). > > > > Yes. Thanks for the link and setting me straight on this too. I'm sure > that I am not the only one who was not fully informed of the reply to > the original rumour. I read the original article on LinuxToday.com. I > now see that they have a link to an article setting this straight > http://www.networkworld.com/community/blog/ubuntu-sticking-six-month-development-cycle > > If people digged a little bit more in the original article, they would not need to set it straight. For having discussed with a Canonical developper, their plan is in the line of what we started to do with backports and mageia-app-db, but integrated in the software center. The main point is the "opportunist developper" plan explained by Jono Bacon some times ago. Ie, people who create small applications, like what they do on the iPhone, but on Linux ( see http://www.jonobacon.org/2010/03/06/the-grand-app-writing-challenge-submissions/ ). And this requires them to be able to deliver theses application on current stable, and maybe on older releases too. So once the required infrastructure is there, it can be reused for more heavyweight backports too. And maybe that's also something to do with the reflexion of Matt Zimmerman ( Canonical CTO ) http://mdzlog.alcor.net/2010/07/06/weve-packaged-all-of-the-free-software-what-now/ -- Michael Scherer
[Mageia-dev] Mirror layout, round two
Hi, As we are getting closer to actually have something to mirror it's time to get this decided. And the deadline for theese discussions is December 5th, 2010 in order to get a decision on the board meeting on December 6th, 2010. Now this is a somewhat problematic topic but needs to be decided. This has already been discussed in two threads: First off we have the "basic) part: "Mirror tree structure" by Olivier Thauvin https://www.mageia.org/pipermail/mageia-dev/20101020/001286.html And the other part (that gives some problems): "Mageia repository sections, licenses, restrictions, firmware etc" by Anssi Hannula. https://www.mageia.org/pipermail/mageia-dev/20101012/001084.html Now, in order to get somewhere, here is a suggestion that tries to find a middle ground or base for discussions... Now this toplevel part seems to be ok by everyone: -- Mageia/ /distrib/ /cauldron/ /stable1/ /iso/ /cauldron/ /i586/ /srpms/ /x86_64/ /stable1/ /people/ /software/ -- Then we come to the "problematic" part: -- /x86_64/ /media/ /codecs/ (disabled by default) /core/ (old main+contrib) /backports/ (disabled by default) /backports_testing/ (disabled by default) /release/ /testing/ (disabled by default) /updates/ /extra/ (unmaintained, disabled by default) /firmware/ (disabled by default) /games/ (disabled by default) /non-free/ (disabled by default) /debug_*/ (disabled by default) - The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. The "core" should be only maintained free/libre stuff so it's easy to build a free/libre iso "extra" is for those packages that no-one really maintain, but is still used by someone "games" are now a separate repo since it can grow fast with a lot of game data. So, Comments / Thoughts... -- Thomas
Re: [Mageia-dev] Mirror layout, round two
On vendredi 26 novembre 2010 at 21:29, Thomas Backlund wrote : > Then we come to the "problematic" part: > -- > x86_64 > media > codecs (disabled by default) > core (old main+contrib) >backports (disabled by default) >backports_testing (disabled by default) >release >testing (disabled by default) >updates > extra (unmaintained, disabled by default) > firmware (disabled by default) > games (disabled by default) > non-free (disabled by default) > /debug_*/ (disabled by default) > - > > The idea of this layout with some of the separate sections (codecs, > firmware, games, non-free, debug_*) gives a mirror maintainer in a > country (or company) the option to exclude the parts they legally (or by > company policy) can not mirror. > > The "core" should be only maintained free/libre stuff so it's easy to > build a free/libre iso > > "extra" is for those packages that no-one really maintain, but is still > used by someone > > "games" are now a separate repo since it can grow fast with a lot of > game data. I think it is a good layout, but, are updates/backports(testing) limited to core? As you mentioned, extra has no reason to have updates or backports, because if someone did bother to make updates, then the package doesn't belong in extra. For games it would surely be appreciated to have new versions, so maybe a only a games/updates media which could also be used as a backport media (as games are not critical). For non-free we would probably want also updates and backports, like in current mandriva. Now for firmware and codecs I don't know, are there updates for firmwares? Maybe they should be in sync with kernel updates (or external modules)? As for codecs, will it contain anything that could be covered by patents, like PLF for mandriva? Does that mean we will still have a stripped down mplayer/xine in core and a full version in codecs? But if it is only disabled and you only need to activate it in the control center to have full featured multimedia programs, it is no big deal, and if it makes life easier for people whose countries have restrictive law then we should go for it. We should probably have a clear rule to decide what cannot go in core and should in non-free (that on is pretty clear already) codecs or firmware. I hope we will soon get to the point where we will actually put packages in those repositories :-) -- Renaud Michel
Re: [Mageia-dev] Mirror layout, round two
Renaud MICHEL skrev 26.11.2010 23:43: On vendredi 26 novembre 2010 at 21:29, Thomas Backlund wrote : Then we come to the "problematic" part: -- x86_64 media codecs (disabled by default) core (old main+contrib) backports (disabled by default) backports_testing (disabled by default) release testing (disabled by default) updates extra (unmaintained, disabled by default) firmware (disabled by default) games (disabled by default) non-free (disabled by default) /debug_*/ (disabled by default) - The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. The "core" should be only maintained free/libre stuff so it's easy to build a free/libre iso "extra" is for those packages that no-one really maintain, but is still used by someone "games" are now a separate repo since it can grow fast with a lot of game data. I think it is a good layout, but, are updates/backports(testing) limited to core? nope, the same layout: backports (disabled by default) backports_testing (disabled by default) release testing (disabled by default) updates should be under codecs, extra, firmware, games, non-free, debug_* in order to provide consistency betwen medias. I just left them out because they was supposed to be the same for all. As you mentioned, extra has no reason to have updates or backports, because if someone did bother to make updates, then the package doesn't belong in extra. Yeah, but for a stable release, we dont move packages... the /release/ must stay frozen. For games it would surely be appreciated to have new versions, so maybe a only a games/updates media which could also be used as a backport media (as games are not critical). To simplify for all users, the medias should be used in the same way. For non-free we would probably want also updates and backports, like in current mandriva. yep. Now for firmware and codecs I don't know, are there updates for firmwares? Not often, but sometimes there are firmwares that get bugfixes, so the same rule apply. Maybe they should be in sync with kernel updates (or external modules)? They must of course stay compatible with the kernel. As for codecs, will it contain anything that could be covered by patents, like PLF for mandriva? Does that mean we will still have a stripped down mplayer/xine in core and a full version in codecs? This is one of the tricky ones... But if it is only disabled and you only need to activate it in the control center to have full featured multimedia programs, it is no big deal, and if it makes life easier for people whose countries have restrictive law then we should go for it. That was the idea. We should probably have a clear rule to decide what cannot go in core and should in non-free (that on is pretty clear already) codecs or firmware. yep. I hope we will soon get to the point where we will actually put packages in those repositories :-) we are getting closer... -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Op vrijdag 26 november 2010 22:43:31 schreef Renaud MICHEL: > On vendredi 26 novembre 2010 at 21:29, Thomas Backlund wrote : > > Then we come to the "problematic" part: > > -- > > x86_64 > > > > media > > > > codecs (disabled by default) > > core (old main+contrib) > > > >backports (disabled by default) > >backports_testing (disabled by default) > >release > >testing (disabled by default) > >updates > > > > extra (unmaintained, disabled by default) > > firmware (disabled by default) > > games (disabled by default) > > non-free (disabled by default) > > /debug_*/ (disabled by default) > > > > - > > > > The idea of this layout with some of the separate sections (codecs, > > firmware, games, non-free, debug_*) gives a mirror maintainer in a > > country (or company) the option to exclude the parts they legally (or by > > company policy) can not mirror. > > > > The "core" should be only maintained free/libre stuff so it's easy to > > build a free/libre iso > > > > "extra" is for those packages that no-one really maintain, but is still > > used by someone > > > > "games" are now a separate repo since it can grow fast with a lot of > > game data. > > I think it is a good layout, but, are updates/backports(testing) limited to > core? > > As you mentioned, extra has no reason to have updates or backports, because > if someone did bother to make updates, then the package doesn't belong in > extra. > > For games it would surely be appreciated to have new versions, so maybe a > only a games/updates media which could also be used as a backport media (as > games are not critical). > > For non-free we would probably want also updates and backports, like in > current mandriva. > > Now for firmware and codecs I don't know, are there updates for firmwares? > Maybe they should be in sync with kernel updates (or external modules)? > As for codecs, will it contain anything that could be covered by patents, > like PLF for mandriva? > Does that mean we will still have a stripped down mplayer/xine in core and > a full version in codecs? > But if it is only disabled and you only need to activate it in the control > center to have full featured multimedia programs, it is no big deal, and if > it makes life easier for people whose countries have restrictive law then > we should go for it. > > We should probably have a clear rule to decide what cannot go in core and > should in non-free (that on is pretty clear already) codecs or firmware. > > I hope we will soon get to the point where we will actually put packages in > those repositories :-) A) i see no reason for codecs and firmware to be separate. However, i do understand that some people would not want to install firmware, but i think we should do this in another way, (like installing a meta package that enforces some limits.) codecs seem odd to be separate, if they have patented problems they should go in non_free, if no problem, they can go in core. B) if they are separate, they would need updates, backports, testing, ... (i expect non_free does too?) C) if they are separate, they cannot be disabled by default, some stuff is needed for stuff to work. D) i have questions about noarch packages, will they be installed on both trees? and if we have more archs later on, more and more? this seems a waste; except if we could hardlink them somehow. if not, we should just put them somewhere separate. E) i understand games to be separate, but disabled by default?, i'm not sure i agree with that. (we need to remember our target audience; stuff needs to work out-of the box) F) what is backports_testing? why can't that just be testing?
Re: [Mageia-dev] Mirror layout, round two
On samedi 27 novembre 2010 at 00:02, Maarten Vanraes wrote : > C) if they are separate, they cannot be disabled by default, some stuff > is needed for stuff to work. I guess you are talking about firmware here. Maybe the installer could detect that a firmware is needed for some hardware, then it could either ask the user if he wants to enable the firmware repository, or automatically enable it. > D) i have questions about noarch packages, will they be installed on > both trees? and if we have more archs later on, more and more? this > seems a waste; except if we could hardlink them somehow. if not, we > should just put them somewhere separate. If the files are identical, they can be hard linked, and then the mirrors updates them with rsync -aH. (by the way, the readme already ask for those options http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/mirror.readme ) It is quite easy to make a script that will make those hard links "à posteriori" (you only need to compare files with identical names) It could even be integrated into the build system (maybe it is already, I have no idea how it works), each time a noarch package is added to a repository it would check the corresponding repository for other arch if the same file is already present and is identical, and if so make a hard link instead of copying it. > E) i understand games to be separate, but disabled by default?, i'm not > sure i agree with that. (we need to remember our target audience; stuff > needs to work out-of the box) This could also be decided at install time. If the user choose the game section then the games repository is enabled and some task-game-* are selected to install various games. > F) what is backports_testing? why can't that just be testing? testing is for packages that will go to updates, backports_testing is for packages that will go to backports. I think it is likely that some people will be willing to test updates candidate but don't want to end up with backports, so enabling only testing and not backports_testing. If I remember correctly, there is currently (mdv2010.1 and previous) no testing stage for backported packages, and it was proposed during the discussion one month ago, that it would be good to have also a testing for backported packages. -- Renaud Michel
Re: [Mageia-dev] Mirror layout, round two
Maarten Vanraes skrev 27.11.2010 01:02: Op vrijdag 26 november 2010 22:43:31 schreef Renaud MICHEL: On vendredi 26 novembre 2010 at 21:29, Thomas Backlund wrote : Then we come to the "problematic" part: -- x86_64 media codecs (disabled by default) core (old main+contrib) backports (disabled by default) backports_testing (disabled by default) release testing (disabled by default) updates extra (unmaintained, disabled by default) firmware (disabled by default) games (disabled by default) non-free (disabled by default) /debug_*/ (disabled by default) - The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. The "core" should be only maintained free/libre stuff so it's easy to build a free/libre iso "extra" is for those packages that no-one really maintain, but is still used by someone "games" are now a separate repo since it can grow fast with a lot of game data. [...] A) i see no reason for codecs and firmware to be separate. However, i do understand that some people would not want to install firmware, but i think we should do this in another way, (like installing a meta package that enforces some limits.) codecs seem odd to be separate, if they have patented problems they should go in non_free, if no problem, they can go in core. That is doable. The reason for having it separate was because its the most "problematic" one. (codecs have more issues than firmware) B) if they are separate, they would need updates, backports, testing, ... (i expect non_free does too?) Yep. as noted in the other post, the layout under /core/ is duplicated under all other medias... C) if they are separate, they cannot be disabled by default, some stuff is needed for stuff to work. So installer could ask "in order to fully support your hw you need ..., do you want to enable firmware repo..." and explain the reason for free/libre... D) i have questions about noarch packages, will they be installed on both trees? and if we have more archs later on, more and more? this seems a waste; except if we could hardlink them somehow. if not, we should just put them somewhere separate. We hardlink them already. But yeah, I'd like a separate noarch too, but some people disagree, so I didnt add it to this proposal. E) i understand games to be separate, but disabled by default?, i'm not sure i agree with that. (we need to remember our target audience; stuff needs to work out-of the box) I was thinking of a feature in the installer, if you select games, it would enable the repo by default, otherwise keep it disabled. F) what is backports_testing? why can't that just be testing? Versioning problem... on mirrors / BS we have testing -> updates route, so this would be backports_testing -> backports, Because if you have this: core/release v 1.2.0-1 core/testing v 1.3.0-1 (intended for backports) then you cant upload a bugfix v 1.2.0-1.1 to core/testing as there is already a bigger version in testing... -- Thomas
Re: [Mageia-dev] Mirror layout, round two
Op zaterdag 27 november 2010 00:25:17 schreef Thomas Backlund: [...] > > A) i see no reason for codecs and firmware to be separate. However, i do > > understand that some people would not want to install firmware, but i > > think we should do this in another way, (like installing a meta package > > that enforces some limits.) > > codecs seem odd to be separate, if they have patented problems they > > should go in non_free, if no problem, they can go in core. > > That is doable. > The reason for having it separate was because its the most "problematic" > one. (codecs have more issues than firmware) What i meant here, is why is firmware separate from core? why is codecs separate from core? imo, i would put firmware and codecs in either core or non_free. > > B) if they are separate, they would need updates, backports, testing, ... > > (i expect non_free does too?) > > Yep. > as noted in the other post, the layout under /core/ is duplicated under > all other medias... yeah, I only read your other post after writing this. > > C) if they are separate, they cannot be disabled by default, some stuff > > is needed for stuff to work. > > So installer could ask "in order to fully support your hw you need ..., > do you want to enable firmware repo..." and explain the reason for > free/libre... that sounds like a good idea, however; do we have the time to change this in the installer? > > D) i have questions about noarch packages, will they be installed on both > > trees? and if we have more archs later on, more and more? this seems a > > waste; except if we could hardlink them somehow. if not, we should just > > put them somewhere separate. > > We hardlink them already. > But yeah, I'd like a separate noarch too, but some people disagree, so I > didnt add it to this proposal. well, especially when we get more archs, we really should separate noarchs; i'm kind of feeling strong about this. > > E) i understand games to be separate, but disabled by default?, i'm not > > sure i agree with that. (we need to remember our target audience; stuff > > needs to work out-of the box) > > I was thinking of a feature in the installer, if you select games, it > would enable the repo by default, otherwise keep it disabled. same as with C) . do we have the time for this? > > F) what is backports_testing? why can't that just be testing? > > Versioning problem... on mirrors / BS > we have testing -> updates route, > so this would be backports_testing -> backports, > > Because if you have this: > core/release v 1.2.0-1 > core/testing v 1.3.0-1 (intended for backports) > > then you cant upload a bugfix v 1.2.0-1.1 to core/testing as there is > already a bigger version in testing... aah, makes sense. PS: i like the extra btw: (which should contain all unmaintained packages that actually build)
Re: [Mageia-dev] Mirror layout, round two
On Sat, Nov 27, 2010 at 00:44, Maarten Vanraes wrote: > Op zaterdag 27 november 2010 00:25:17 schreef Thomas Backlund: > [...] >> > A) i see no reason for codecs and firmware to be separate. However, i do >> > understand that some people would not want to install firmware, but i >> > think we should do this in another way, (like installing a meta package >> > that enforces some limits.) >> > codecs seem odd to be separate, if they have patented problems they >> > should go in non_free, if no problem, they can go in core. >> >> That is doable. >> The reason for having it separate was because its the most "problematic" >> one. (codecs have more issues than firmware) > > What i meant here, is why is firmware separate from core? why is codecs > separate from core? > > imo, i would put firmware and codecs in either core or non_free. I guess we should separate concerns? - non_free as in "not (really) free software" (source code may be available, but license, redistribution conditions, etc.) - problematic stuff as in "binary closed thing" (most firmware, but not only eventually) - problematic stuff as in "(likely) patented" (some codecs) so that we don't mix issues when one has to decide what to mirror/use or not. Romain
Re: [Mageia-dev] Mirror layout, round two
Op zaterdag 27 november 2010 00:51:59 schreef Romain d'Alverny: > On Sat, Nov 27, 2010 at 00:44, Maarten Vanraes > > wrote: > > Op zaterdag 27 november 2010 00:25:17 schreef Thomas Backlund: > > [...] > > > >> > A) i see no reason for codecs and firmware to be separate. However, i > >> > do understand that some people would not want to install firmware, > >> > but i think we should do this in another way, (like installing a meta > >> > package that enforces some limits.) > >> > codecs seem odd to be separate, if they have patented problems they > >> > should go in non_free, if no problem, they can go in core. > >> > >> That is doable. > >> The reason for having it separate was because its the most "problematic" > >> one. (codecs have more issues than firmware) > > > > What i meant here, is why is firmware separate from core? why is codecs > > separate from core? > > > > imo, i would put firmware and codecs in either core or non_free. > > I guess we should separate concerns? > - non_free as in "not (really) free software" (source code may be > available, but license, redistribution conditions, etc.) > - problematic stuff as in "binary closed thing" (most firmware, but > not only eventually) > - problematic stuff as in "(likely) patented" (some codecs) > > so that we don't mix issues when one has to decide what to mirror/use or > not. you know what? how about having a "possibly_patented" and disable it by default; but have them all in there. because there are countries where most of those are allowed. (i suspect they aren't necessarily codecs) how about having a "binary_only" repository? (i suspect they aren't all firmwares?) or they could just be in non_free; because that's what they are...
Re: [Mageia-dev] Mirror layout, round two
Op zaterdag 27 november 2010 00:51:59 schreef Romain d'Alverny: > On Sat, Nov 27, 2010 at 00:44, Maarten Vanraes > > wrote: > > Op zaterdag 27 november 2010 00:25:17 schreef Thomas Backlund: > > [...] > > > >> > A) i see no reason for codecs and firmware to be separate. However, i > >> > do understand that some people would not want to install firmware, > >> > but i think we should do this in another way, (like installing a meta > >> > package that enforces some limits.) > >> > codecs seem odd to be separate, if they have patented problems they > >> > should go in non_free, if no problem, they can go in core. > >> > >> That is doable. > >> The reason for having it separate was because its the most "problematic" > >> one. (codecs have more issues than firmware) > > > > What i meant here, is why is firmware separate from core? why is codecs > > separate from core? > > > > imo, i would put firmware and codecs in either core or non_free. > > I guess we should separate concerns? > - non_free as in "not (really) free software" (source code may be > available, but license, redistribution conditions, etc.) > - problematic stuff as in "binary closed thing" (most firmware, but > not only eventually) > - problematic stuff as in "(likely) patented" (some codecs) > > so that we don't mix issues when one has to decide what to mirror/use or > not. > > > Romain imo, non_free should contain software that's allowed to be redistributed but: - has conditions - has no redistributable source - has restrictions - etc...
Re: [Mageia-dev] Mirror layout, round two
On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund wrote: > > The idea of this layout with some of the separate sections (codecs, > firmware, games, non-free, debug_*) gives a mirror maintainer in a country > (or company) the option to exclude the parts they legally (or by company > policy) can not mirror. > I wonder how "urpmi.addmedia --distrib ftp://server/with/omitted/sections"; should be interpreted then. Also mirror list should be indicating which sections are present; is it supported right now?
Re: [Mageia-dev] Mirror layout, round two
2010/11/27 Andrey Borzenkov : > On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund wrote: >> >> The idea of this layout with some of the separate sections (codecs, >> firmware, games, non-free, debug_*) gives a mirror maintainer in a country >> (or company) the option to exclude the parts they legally (or by company >> policy) can not mirror. >> > > I wonder how "urpmi.addmedia --distrib > ftp://server/with/omitted/sections"; should be interpreted then. > > Also mirror list should be indicating which sections are present; is > it supported right now? And that will make the "$MIRRORLIST" approach problematic. Say I am living in a country which has no patent restrictions but no mirror either. Then the addmedia function will search a mirror in my neighborhood and selects the next mirror which may be such a mirror where the maintainer excluded the parts with patented software. Say I am a new user who does not know about the option to manually select a mirror and who does not know that such mirrors with missing branches do exist. I must come to the conclusion that Mageia does not distribute any patented software at all. This can only be avoided on user level by asking the user first if he wants patented software or not (including a text which explains the problem). Then if he wants to have patented software he could be connected to a mirror with the "patented software flag", if not he will be connected with a mirror which does not have the "patented software flag". The other option may be that we do not allow mirrors without the "patented" branch in the official mirrorlist. This would probably mean no official mirrors in those countries with "patent problems" but people there can still use other "off shore" mirrors. -- wobo
Re: [Mageia-dev] Mirror layout, round two
On 27 November 2010 08:27, Andrey Borzenkov wrote:
> On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund wrote:
>>
>> The idea of this layout with some of the separate sections (codecs,
>> firmware, games, non-free, debug_*) gives a mirror maintainer in a country
>> (or company) the option to exclude the parts they legally (or by company
>> policy) can not mirror.
>>
>
> I wonder how "urpmi.addmedia --distrib
> ftp://server/with/omitted/sections"; should be interpreted then.
>
> Also mirror list should be indicating which sections are present; is
> it supported right now?
>
IMHO, the mirrorlist in its current status should be dropped
altogether... it's only good if the user has good mirrors near where
he lives, otherwise it just fails miserably. The whole point of using
a mirrorlist was that "urpmi will switch to another mirror if the
currently used one fails / can't be reached", that switch doesn't
happen, ("md5sum mismatch" rings a bell?).
At least with the specific media mirrors the user can, more easily,
guess that he can use add another mirror, with mirrorlist most new
users are left clueless.
--
Ahmad Samir
