Maarten Vanraes a écrit :
Op woensdag 01 december 2010 21:54:48 schreef andre999:
[...]
allthough interesting, this thread is about mirror layout; and is not about
removing the distinction between supported packages and not. (this wasn't all
that clear to me at first.)
I'll discuss further down why I think that this is a critical part of
the question.
i do understand that you think other methods of having the distinction might
not work; i have reservations myself that way. (i do feel the disctinction is
important.)
Glad to see that you understand my concerns.
i also see that mirror layout should be as easy as possible for mirror admins.
Agreed. However keeping an extra set of repositories for core packages
would just add a few extra directories (without changing the number/size
of their total content), thus have little impact on mirror administration.
However "tainted" repositories, being optional, would be more problematic.
Especially, as others pointed out, for the larger multi-project mirror
sites, where admins are already distracted by many other demands.
On the other hand, I see the point of adding "tainted".
Since it is for packages that are likely to be problematic in *some*
countries, I imagine that relatively few of these larger mirror admins
would feel the need to exclude "tainted".
(And for the same reason my quibble about choosing a more neutral name,
such as "restricted". Or maybe even "problematic". For countries where
these packages would be acceptable.)
In any case, rsync is a pretty straight-forward application.
however, looking at the big picture, i think that logically it's sounds to
have one purpose to one thing; and thus for the mirror layout; only the mirror
admins should be looked at; the viewpoint of a user _should_ not really
matter.
I agree that the user viewpoint is not of major importance : I see that
as just a positive side effect.
I am trying to look at the big picture. And perhaps I haven't been very
effective at expressing my concerns.
In my mind, we should always consider important side effects of major
changes. And removing separate "core"/"extra" (or "main"/"contrib"
repositories does have an important side effect.
Realigning "core" so it is really core should very much help packagers,
as well as maintaining an important distinction.
Note that if, down the road, we find another effective method for
distinquishing core / non-core, it is relatively simple to transfer
packages in "extra" to "core".
But if we eliminate the parallel set of repositories, and find later
that we have a problem giving priority to core packages, moving in the
other direction would be a much more difficult process.
The suggestion that we only transfer to Mageia packages that we see as
important to keep, sounds like a very good approach.
This would also facilitate maintaining the core / non-core distinction.
I'm not trying to say that defining core / non-core in detail is a
trivial process. But it is in the interest of Mageia to define it.
I realise, at least at first, that things will be more difficult for
packagers. But firmly believe that this will be largely alleviated by a
careful triage of existing "main" and "contrib" packages.
Thus I am more than willing to put in a lot of effort, since it will
have an important impact on the future of Mageia.
I also realise that many of those proposing eliminating a set of repos
have a lot of valuable experience. And I'm sure that if/when we can
agree on this concern, that we will be able to work very well together.
And I look forward to becoming a Mageia packager.
another 2 cents :)
- André
