libogg and upgrading core packages policy (was: video in the desktop)

[Ville Skyttä]

On Sat, 2004-06-19 at 09:01, Axel Thimm wrote:

> Honestly, I don't see a reason for all this "don't upgrade core
> packages because you will introduce instability" while at the same
> time kernel modules are deployed w/o any hesitation. kernel modules
> are upgrades to the kernel even if not technically from rpm's POV, and
> such upgrades are far more severe that upgrading libogg.

They are not the same thing, and it is not about stability/instability,
it's about providing the possibility to choose.

Stuffing core package updates into the same repository with rest of the
extras/alternatives means that without frequent black magic
apt/yum/up2date pinning etc configuration changes (and I don't know if
it's even possible in yum/up2date), people do not have the choice not to
have core updates, they may be unintentionally installed.  Pulling in
new kernel modules does not happen without explicitly asking for them
(for the first time, anyway).

Possibility to choose was a repository design requirement at the time
fedora.us started, and the patches repository implements that.  For
whatever reasons, probably mostly due to it not being advertized enough
and not being in the default configurations nor really properly
documented anywhere, people dislike the current implementation.

On the other hand, when patches was designed and implemented, fedora.us
was targeting distributions that were officially supported by Red Hat. 
Thus the requirement to provide the "no core updates" choice to users
was generally more important than what it is today where none of the
target distros have formal RH support.  Today, 3rd party organizations
do provide formal support for older distributions, so the issue still
exists, but affects a smaller number of users.

> So make your life easier and simply put the packages there were people
> expect them, e.g. not is some obscure patches, alternatives etc.

I don't see why the possibility to choose should be removed.  Getting
rid of the obscurity, eg. through documenting the patches repo properly
and including it in the default configurations would be a lot better
approach IMO.