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
