libogg and upgrading core packages policy

[Axel Thimm]

On Sat, Jun 19, 2004 at 03:14:16PM +0300, Ville Skyttä wrote:
> 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.

Yes, but choose based on what criteria? security, stability and
functionality is what you check for.

The argument of some (all?) repos carrying updates to the vendor repo
is almost exclusively used with the background of stability.

And where will you draw the line of packages pulled in by
dependencies? At run-time requirements? Build-time? The proper thing
would be the latter. A lot of packages for instance require updated
build tools (autotools and sometimes even make), so you'll have a
larger collateral pull-in effect.

> 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.

Well, people dislike it, because some folks have been doing lots of PR
against upgrading vendor supplied packages, usually in the sense that
repo ABC is bad because it does so, so choose repo XYZ. You all know
who these folks are ...

Anyway a patches/alternatives etc separation will become more and more
obscure when you discover that you need to shove over gstreamer
(parts), mplayer4theora, transscode_tng_legal and so on to "patches"
due to one vendors lib (libogg) having been updated. The rest would
have been pulled over to US-non-legal sections.

So currently fedora.us has 2x3x3 = 18 repos (US-legal/not, 3 x
stability classes, 3 x released/in-release progress/alternatives).

That's quite a lot for a single source of packages, isn't it? ;)
E.g. for using transcode with libtheora enabled you would have to use
_three_ subrepos.

What the user wants is to have stability classification in order to
tune security/stbility vs functionality to his given situation. The
US-legal/US-non-legal problem is less an issue for him, but is
sometimes mandatory for projects hosted in the US. I would not add
another layer to that (yes the layer is almost already there with
"patches", but as you mentioned it is treated like the flu).
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040619/351cbdda/attachment.sig>