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