libogg and upgrading core packages policy

[Axel Thimm]

On Sat, Jun 19, 2004 at 06:43:03PM +0200, Axel Thimm wrote:
> 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.

And what I forgot to add, is how will you cope with the bookkeeping
nightmare with different distros defining packages as upgrades or new?

For example say foo-1.0 was packaged for FC2 outside the vendor. It is
introduced in FC3, so you don't need to repackge it.

But now you have a need for foo-1.1 for both FC2 and FC3. For FC3 it
becomes "alternatives" pulling in all dependent packages. For FC2 it
is either "new", so get to its standard place and a different set of
alternatives emerge, or you make bookkeeping easier but inconsistent
by defining foo as "alternatives" for FC2 also. Playing this through
with older distros you find that all of your repo becomes
"alternative" ;)

Repo subsegmentation upon contents of the vendor repo is flawed, this
is why nobody accepted the "Fedora Extras/Alternatives" split even
when the concept is now 3/4 year old, and was often proposed to the
repo folks.

> > 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/02a4e022/attachment.sig>