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)
