Re: [Mageia-dev] Mirror layout, round two
On 10/11/30 00:29 -0500, andre999 wrote:
My point is that a sandbox will facilitate proper support. Which
would be facilitated by keeping the 2 sets of free repositories.
And restricting what should be considered core.
We both know that Mandriva is moving in that direction. Evidently
recognising that they weren't restrictive enough in the past.
Your focus is removing 1 of these repository sets, and thus the sandbox.
But I don't see your solution for giving priority to maintaining
core packages ?
These factors are undeniably linked.
no they're not. the problem is the lack of maintainers.
your answer: it is in core media, so people will acknowledge it's
important and will step in.
guess what? they won't. history suggests that. the following too:
https://maint.mandriva.com/listpkgs.php?owner=1media=1scount=1000
you will answer that those packages should not be in main, but in extra
since they aren't really core (your definition of core). but most of
them are in main because of buildrequires dependencies. so what to do?
and by having 2 medias, you are increasing the work of potential
packagers. and their frustration. trust me on this - been there, done
that.
now michael's answer: broken? no one steps in? removed from mageia.
does it suck? yes. as a user, i prefer having lots of packages
available, since it means that i won't have to package it myself if/when
i need the tool.
but it has a great virtue: it passes reality check. less packages means
less work for the small pool of maintainer. and it may force people to
step in ('cause there's an impacting action that will happen otherwise)
rather than handwaving. which increases the pool of maintainer.
so i'm in favour of misc's proposal.
jérôme
--
jque...@gmail.com
Re: [Mageia-dev] Mirror layout, round two
On Sat, Nov 27, 2010 at 11:16:57PM +0100, Maarten Vanraes wrote: Op zaterdag 27 november 2010 22:07:43 schreef Michael scherer: On Sat, Nov 27, 2010 at 08:23:59PM +0200, Thomas Backlund wrote: Jerome Quelin skrev 27.11.2010 19:11: On 10/11/27 17:59 +0100, Maarten Vanraes wrote: and, more importantly: what is the advantage? that is, what does that bring you, except more admin? QA! and enduser satisfaction. Just take a look on many bugreports in MDV Bugzilla. If the report is against a nomaintainer@ package, currently Triage pretty much only can state thanks for your report, but since it has no maintainer, nothing will probably happend wich is not good answer for a person that have taken the time to report a bug. Then why don't we either : - decide that non maintened package must be taken care by trainee, as part of the training - decide to clean them. that's a great idea, we need more trainees! but of course, we can't do that with all 5000+ unmaintained packages... is there a way to get rpm usage stats from those unmaintained packages. No. We can only get download stats from mirrors. While it may be biased toward some geographical preference ( ie, I doubt many people download locale-zh from distrib-coffee ), it can give at least some ideas. Nothing precise, but still better than random. By having the /extra/ disabled by default, and a popup notifying the user if he enables it that the packages are unmaintained he knows he's on his own That's already what the GPL say, basically :) ( you have no garantee of anything ). Yet, I fail to see what benefit it does really bring to users. Most of them will enable the media ( because some people enable everything ), will forget the message ( because we always forget popup, thanks to endless abuse of such popup ), and the only benefit is that we could tell we told you. Not really satisfying, and if I was a user, it would not really please me, nor inspire confidence. some would, but that they'd also enable testing, backports, debug, etc... if they really do so, it's kind of their own fault. i don't think the majority does that. the majority leaves it at default. And so the majority will say $distro is bad because there is not enough software. The thing is that you have no guarantee, but the thing is, with mdv, there's too much packages that just don't work; you install it, you click in the menu and nothing happens because it doesn't work. So too much is 10%, more ? same thing and one of them is in extra; then i get only one, if i can't find any, i can enable the searching in extra and try to find a package that works. that's why i personally would prefer to leave these off by default. We could avoid adding a media by merging this media with core, and show the popup when a user install a package without maintainer, telling either beware, this package is currently marked as not maintained, and may be buggy. We will try to do what we can to help in this case, but no one is officialy in charge or we are seeking help on taking care of this package, if you use it often, please register on $URL this popup will get ignored too; and persons who are perfectly aware of it, will grow irritated. Then, we can do a single do not ask me again, or just show it once ? futhermore: (no separate extra) - huge amount of packages (think of the mirrors) mirror space is taken with extra or core. So the argument do not stand much. Now, this would be a arguent for simply erasing those unmaintained packages. - huge hdlists Indeed. But if we want to have people be able to search inside like you said you would, this would still be downloaded, be used ( so in memory ) and on the mirror. So that's also not much a good reason. ( however, if we remove them... ) -- Michael Scherer
Re: [Mageia-dev] Mirror layout, round two
On dimanche 28 novembre 2010 at 21:12, Thomas Backlund wrote : So the mirror medias accordingly to all comments so far would be a simple: * core - enabled by default - mirrors must mirror this media to be listed as a mirror - only GPL stuff I guess you meant free (as defined by FSF, or we can make our own definition, like debian), we surely don't want to restrict ourself to GPL- only stuff. - must be selfcontained * nonfree - disabled by default, installer will ask to enable it if it detects hw that need driver/fw from here... - mirrors must mirror this media to be listed as a mirror - contains apps/drivers/firmware that are free to redistribute, but we dont have GPL source for - for example ati/nvidia drivers/firmware, Oracle Java, ... * tainted - disabled by default - mirrors are free to not mirror this media - stuff we think we can redistribute, but that may have some patent issues or other restrictions in oter countries. Merging codecs and firmware into tainted makes sense. So games and extra gets merged back into core (except for non-free games of course), won't this make an enormous repos? I think it was better to have a separated games repos, as it will quickly get big, and is likely to have frequent backports (as gamers generally want to have the latest release). Would it be possible to have a separate games sub-project, that won't freeze to make releases with the rest of mageia? Instead it would be an always updating repos which is compiled with the latest stable release (or even the previous, if it is possible to have packages that install correctly on both). The project would only have a testing and release (or another name to avoid confusion with other release repos which are frozen), this way you could quickly have new versions of all the games, if they don't need bleeding-edge libraries (I think they rarely does). -- Renaud Michel
Re: [Mageia-dev] Mirror layout, round two
On Sunday 28 November 2010 23:10:34 Thomas Backlund wrote: [...] Would it be possible to have a separate games sub-project, that won't freeze to make releases with the rest of mageia? Instead it would be an always updating repos which is compiled with the latest stable release (or even the previous, if it is possible to have packages that install correctly on both). The project would only have a testing and release (or another name to avoid confusion with other release repos which are frozen), this way you could quickly have new versions of all the games, if they don't need bleeding-edge libraries (I think they rarely does). Interesting idea, but problem is that if the games are built against some newer system libs, they'll stop working on older releases... Is it possible to have a « repository » in stable release working as « unstable » release : if we push version n+1 in this repository then the version n is going to be removed to save spaces ? Regards, -- Balcaen John
Re: [Mageia-dev] Mirror layout, round two
Le dimanche 28 novembre 2010 à 22:12 +0200, Thomas Backlund a écrit : So the mirror medias accordingly to all comments so far would be a simple: * core - enabled by default - mirrors must mirror this media to be listed as a mirror - only GPL stuff - must be selfcontained * nonfree - disabled by default, installer will ask to enable it if it detects hw that need driver/fw from here... - mirrors must mirror this media to be listed as a mirror - contains apps/drivers/firmware that are free to redistribute, but we dont have GPL source for - for example ati/nvidia drivers/firmware, Oracle Java, ... * tainted - disabled by default - mirrors are free to not mirror this media - stuff we think we can redistribute, but that may have some patent issues or other restrictions in oter countries. 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
Re: [Mageia-dev] Mirror layout, round two
On Sun, Nov 28, 2010 at 8:06 PM, Olivier Thauvin nanar...@nanardon.zarb.org wrote: I can't agree with the mirrors are free to not mirror this media, three reasons: 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
Re: [Mageia-dev] Mirror layout, round two
Op maandag 29 november 2010 01:24:42 schreef Michael scherer: On Sat, Nov 27, 2010 at 08:00:17PM +0200, Thomas Backlund wrote: Michael scherer skrev 27.11.2010 10:43: On Fri, Nov 26, 2010 at 10:29:14PM +0200, Thomas Backlund wrote: [...] Then we come to the problematic part: This part look really too complex to me. -- /x86_64/ /media/ /codecs/ (disabled by default) so, ogg, webm, being codec, should go there or not ? What about patents problem about something else than codec ? ( freetype, image such as gif, DRM stuff ) Actually this is the maybe_legal_greyzone repo, but since flagging it as codecs would really make people react, I named it so for now... Sorry to be so direct, but that's doesn't answer the question :/ /core/ (old main+contrib) /backports/ (disabled by default) /backports_testing/ (disabled by default) /release/ /testing/ (disabled by default) 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 ). /updates/ /extra/ (unmaintained, disabled by default) If used by people, then why no one step to maintain anything ? Yeah, thats the problem. 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 ? And reality shows we have a lot of packages assigned to nomaintainer@ ... /firmware/ (disabled by default) Why separate firmware from non_free ? What does it bring ? Since both of them are disabled by default, they can be simply merged. Well, this suggestion is partly based on the fact that we have users that want a firmware free install, wich this would satisfy... 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 ). But yes, if we ignore those suggestions, we split the firmwares in GPL - /core/ and the rest to /non-free/ /games/ (disabled by default) That's a simplification that make no sense. Not all games are big, not all big packages are games ( tetex, openoffice ). It's not only a size question, its also a nice option for companies to not mirror games (employees should work, not play...) 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. And we have some contributors that already have stated that they plan to add all possible games so it will grow. and we all know games are the fastest growing /space demanding... 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
Re: [Mageia-dev] Mirror layout, round two
Op maandag 29 november 2010 02:06:13 schreef Olivier Thauvin: * Thomas Backlund (t...@iki.fi) wrote: So the mirror medias accordingly to all comments so far would be a simple: * core - enabled by default - mirrors must mirror this media to be listed as a mirror - only GPL stuff - must be selfcontained * nonfree - disabled by default, installer will ask to enable it if it detects hw that need driver/fw from here... - mirrors must mirror this media to be listed as a mirror - contains apps/drivers/firmware that are free to redistribute, but we dont have GPL source for - for example ati/nvidia drivers/firmware, Oracle Java, ... * tainted - disabled by default - mirrors are free to not mirror this media - stuff we think we can redistribute, but that may have some patent issues or other restrictions in oter countries. 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. 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
Re: [Mageia-dev] Mirror layout, round two
Op maandag 29 november 2010 01:51:38 schreef Michael Scherer: Le dimanche 28 novembre 2010 à 22:12 +0200, Thomas Backlund a écrit : So the mirror medias accordingly to all comments so far would be a simple: * core - enabled by default - mirrors must mirror this media to be listed as a mirror - only GPL stuff - must be selfcontained * nonfree - disabled by default, installer will ask to enable it if it detects hw that need driver/fw from here... - mirrors must mirror this media to be listed as a mirror - contains apps/drivers/firmware that are free to redistribute, but we dont have GPL source for - for example ati/nvidia drivers/firmware, Oracle Java, ... * tainted - disabled by default - mirrors are free to not mirror this media - stuff we think we can redistribute, but that may have some patent issues or other restrictions in oter countries. 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. 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)
Re: [Mageia-dev] Mirror layout, round two
* Maarten Vanraes (maarten.vanr...@gmail.com) wrote: Op maandag 29 november 2010 01:24:42 schreef Michael scherer: 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 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). 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 ). 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 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). 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 ♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖ pgpUoLxjmkCuV.pgp Description: PGP signature
Re: [Mageia-dev] Mirror layout, round two
2010/11/27 Ahmad Samir ahmadsamir3...@gmail.com: 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?). Although I am a friend of SmartUrpmi and EasyUrpmi I do understand the easy way the mirrorlist system provides, especially for new users. The failure of this system due to failing mirrors was already discussed at Mandriva and there is a bug in MDv bugzilla about it - still open. But even if this bug could be fixed, the option for mirror maintainers to exclude parts of the official mirror structure puts the mirrorlist system in jeopardy, unless we have 2 mirrorlists, one with and one without problematic software and let the user select one or the other before he sets up his media. -- wobo
Re: [Mageia-dev] Mirror layout, round two
On Fri, Nov 26, 2010 at 10:29:14PM +0200, Thomas Backlund wrote: 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: This part look really too complex to me. -- /x86_64/ /media/ /codecs/ (disabled by default) so, ogg, webm, being codec, should go there or not ? What about patents problem about something else than codec ? ( freetype, image such as gif, DRM stuff ) /core/ (old main+contrib) /backports/ (disabled by default) /backports_testing/ (disabled by default) /release/ /testing/ (disabled by default) /updates/ /extra/ (unmaintained, disabled by default) If used by people, then why no one step to maintain anything ? If someone take the maintainace, does it mean that we will move the package ? /firmware/ (disabled by default) Why separate firmware from non_free ? What does it bring ? Since both of them are disabled by default, they can be simply merged. /games/ (disabled by default) That's a simplification that make no sense. Not all games are big, not all big packages are games ( tetex, openoffice ). This only bring complexity on our side, complexity on mirror side, and bring few improvement to users. A rather more precise label would be to have /contents/ repository, as this is not the game that take space, but the content. And a explicit policy of splitting content from big packages, with a explicit size or expected size for limit ( like if the package is more than 100 mo ). That's also a media where deltarpm would make sense, or someting like that. In the mean time this would only bring complexity to everybody else. /non-free/ (disabled by default) /debug_*/ (disabled by default) And what are the relation of requirements ? Ie, what can requires non_free, codecs, games, etc ? And what about something that can goes in both media, ie a non_free game goes where ? A unmaintained codecs goes where ? -- Michael Scherer
Re: [Mageia-dev] Mirror layout, round two
2010/11/27 Maarten Vanraes maarten.vanr...@gmail.com: if a mirror doesn't have some repositories, it should fetch the next one. In this case there has to be some kind of selection dialogue on the user side to determine which repositories the user wants to set up. No need to let urpmi go to the next mirror if the user does not want Games (or codecs or any other non core branch). The more we differentiate the more komplex the whole thing becomes for all sides.
Re: [Mageia-dev] Mirror layout, round two
Op zaterdag 27 november 2010 14:21:28 schreef Wolfgang Bornath: 2010/11/27 Maarten Vanraes maarten.vanr...@gmail.com: if a mirror doesn't have some repositories, it should fetch the next one. In this case there has to be some kind of selection dialogue on the user side to determine which repositories the user wants to set up. No need to let urpmi go to the next mirror if the user does not want Games (or codecs or any other non core branch). The more we differentiate the more komplex the whole thing becomes for all sides. i mean, if a certain media is enabled, and that media isn't on the mirror you're using, mirrorlist should automagically choose the next one.
Re: [Mageia-dev] Mirror layout, round two
On 10/11/27 17:59 +0100, Maarten Vanraes wrote: i agree, the less repositories the easier it'll be. however, core is for all the maintained packages, extra is for the unmaintained packages that build ok. what is a maintained package? no maintainer, no commits since x months, not buildable? what if we move to packages being maintained by foo...@packages.mageia.org aliases? what are the rules to move a package from extra to core, and vice-versa? who can do it? will it be done automatically? will this imply a rebuild for the package? what are the dependency rules? can a core package depend on an extra package? or with a buildrequires? and, more importantly: what is the advantage? that is, what does that bring you, except more admin? sorry, consider me not impressed by this idea. or maybe it's just that i failed to see the benefits. please enlighten me. jérôme -- jque...@gmail.com
Re: [Mageia-dev] Mirror layout, round two
Op zaterdag 27 november 2010 18:11:36 schreef Jerome Quelin: On 10/11/27 17:59 +0100, Maarten Vanraes wrote: i agree, the less repositories the easier it'll be. however, core is for all the maintained packages, extra is for the unmaintained packages that build ok. what is a maintained package? no maintainer, no commits since x months, not buildable? what if we move to packages being maintained by foo...@packages.mageia.org aliases? what are the rules to move a package from extra to core, and vice-versa? who can do it? will it be done automatically? will this imply a rebuild for the package? what are the dependency rules? can a core package depend on an extra package? or with a buildrequires? and, more importantly: what is the advantage? that is, what does that bring you, except more admin? sorry, consider me not impressed by this idea. or maybe it's just that i failed to see the benefits. please enlighten me. jérôme you pose good questions. a maintained package is a package that has (at least one) maintainer. i would propose making the maintainer structure more efficient and not like mandriva; if someone stops being a maintainer, he (or someone else) should drop his package(s). some packages don't require much maintenance. I would say that extra is not essential for mirrors to have; so if it's a package that is essential, it's better to find someone who can maintain it. if not; we should drop it into extra (i would say, before cauldron freeze time) and all packages it depends on. IMHO. the advantage could be that mirrors don't need to mirror those packages. (extra will be like the unmaintained contrib from mdv) i foresee too that at least in the beginning, this 'll be bigger than core. which brings us to another advantage: the hdlists; those are huge enough as it is. and extra will very likely not be changed much. these are my thoughts. (PS: since imo only core is required, no core package can have any dependency on any other repository)
Re: [Mageia-dev] Mirror layout, round two
Jerome Quelin skrev 27.11.2010 19:11: On 10/11/27 17:59 +0100, Maarten Vanraes wrote: i agree, the less repositories the easier it'll be. however, core is for all the maintained packages, extra is for the unmaintained packages that build ok. what is a maintained package? no maintainer, no commits since x months, not buildable? what if we move to packages being maintained by foo...@packages.mageia.org aliases? if maintainer db says nomaintainer@ it belong in /extra/ what are the rules to move a package from extra to core, and vice-versa? who can do it? will it be done automatically? will this imply a rebuild for the package? If a maintainer picks up maintainership of a package in /extra/ it will be rebuilt and moved to /core/ asap. if a package in /core/ ends up nomaintainer@, then after a grace period (1-3 months ?) it will be moved to /extra/. and sometime before RC1 or so, any momaintainer@ package in /core/ will get moved to /extra/ as for a release the /core/ should only contain maintained packages. what are the dependency rules? can a core package depend on an extra package? or with a buildrequires? No. If you need to build against a package in /extra/, either pick up the maintainership of it, or try to get someone other to maintain it. then it can get into /core/ and, more importantly: what is the advantage? that is, what does that bring you, except more admin? QA! and enduser satisfaction. Just take a look on many bugreports in MDV Bugzilla. If the report is against a nomaintainer@ package, currently Triage pretty much only can state thanks for your report, but since it has no maintainer, nothing will probably happend wich is not good answer for a person that have taken the time to report a bug. By having the /extra/ disabled by default, and a popup notifying the user if he enables it that the packages are unmaintained he knows he's on his own sorry, consider me not impressed by this idea. or maybe it's just that i failed to see the benefits. please enlighten me. -- Thomas
Re: [Mageia-dev] Mirror layout, round two
On Sat, Nov 27, 2010 at 08:23:59PM +0200, Thomas Backlund wrote: Jerome Quelin skrev 27.11.2010 19:11: On 10/11/27 17:59 +0100, Maarten Vanraes wrote: what are the rules to move a package from extra to core, and vice-versa? who can do it? will it be done automatically? will this imply a rebuild for the package? If a maintainer picks up maintainership of a package in /extra/ it will be rebuilt and moved to /core/ asap. if a package in /core/ ends up nomaintainer@, then after a grace period (1-3 months ?) it will be moved to /extra/. and sometime before RC1 or so, any momaintainer@ package in /core/ will get moved to /extra/ as for a release the /core/ should only contain maintained packages. But isn't it in contradiction with the fact that release should not be changed ? IE, a package could be in core for one release, and extras in another. What happen to such shrodingerian packages ? What happen if this break the self containement ? And finally, isn't it redoing contribs/main , leading in the future to the same problem we tried to avoid ? what are the dependency rules? can a core package depend on an extra package? or with a buildrequires? No. If you need to build against a package in /extra/, either pick up the maintainership of it, or try to get someone other to maintain it. then it can get into /core/ And so, if no one step, wouldn't it be like current mdv, where people will say they maintain the package just because someone has to do the job ? and, more importantly: what is the advantage? that is, what does that bring you, except more admin? QA! and enduser satisfaction. Just take a look on many bugreports in MDV Bugzilla. If the report is against a nomaintainer@ package, currently Triage pretty much only can state thanks for your report, but since it has no maintainer, nothing will probably happend wich is not good answer for a person that have taken the time to report a bug. Then why don't we either : - decide that non maintened package must be taken care by trainee, as part of the training - decide to clean them. By having the /extra/ disabled by default, and a popup notifying the user if he enables it that the packages are unmaintained he knows he's on his own That's already what the GPL say, basically :) ( you have no garantee of anything ). Yet, I fail to see what benefit it does really bring to users. Most of them will enable the media ( because some people enable everything ), will forget the message ( because we always forget popup, thanks to endless abuse of such popup ), and the only benefit is that we could tell we told you. Not really satisfying, and if I was a user, it would not really please me, nor inspire confidence. We could avoid adding a media by merging this media with core, and show the popup when a user install a package without maintainer, telling either beware, this package is currently marked as not maintained, and may be buggy. We will try to do what we can to help in this case, but no one is officialy in charge or we are seeking help on taking care of this package, if you use it often, please register on $URL -- 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
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
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 maarten.vanr...@gmail.com 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 maarten.vanr...@gmail.com 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
On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund t...@iki.fi 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 arvidj...@gmail.com: On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund t...@iki.fi 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 arvidj...@gmail.com wrote: On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund t...@iki.fi 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
