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
Attachment:
pgp6VislDR35l.pgp
Description: PGP signature
