Yum Problems on FC4 x86_64

[Les Mikesell]

On 8/3/05, Michael Schwendt <mschwendt.tmp0501.nospam at arcor.de> wrote:

> > the livna repository not only 'plays
> > nice' with the official core/extra repositories but it requires you
> > to use them because packages that exist in core/extras aren't duplicated
> > at livna and are often dependencies in the livna packages.
> 
> Primarily, this is due to resource problems. The combination of Fedora
> Extras and Fedora Core is seen as an extended base repository. What
> is in Core and Extras already, doesn't need to be maintained separately.

And in my opinion, shouldn't be maintained separately since that would
likely introduce conflicts where none exist now.

> However, it's not that easy, as sometimes packages may have build
> requirements, which are newer than what is found in Core or Extras. Think
> CVS snapshots or bleeding edge releases, which somebody at livna.org would
> like to package because of major bug fixes or feature improvements. Even
> if the package developer at Extras were asked, it may not be easily
> feasible to upgrade something in Extras only because an external
> repository needs a newer version.

Instead of making a conflicting package with the same name, why can't
a new package be created in a way that the duplicate can co-exist with
the stock package?  There are probably exceptions where this isn't possible
but simple libraries, etc. could be renamed or put in another location.  That
way you don't have to guess what broke when the core/extra version is
updated and clobbers the modified one you needed.   If I want the features,
I'll put up with the space the extra copy takes.

> > I'm not
> > quite sure why the other 3rd party repositories don't work that way
> > too.  I understand it with earlier releases where there are
> > compatibility problems with pre-existing packages, but at this point
> > what justification is there for anyone to build a package that
> > conflicts with core/extras?
> 
> Well, there are several reasons, some known, some not. For instance, not
> all 3rd party repos have the same goal. Packages in Extras may not build
> for Red Hat Enterprise Linux.

Centosplus might be the right home for these...

> This would require extra effort, when
> binary packages for multiple distributions are built from the same
> src.rpm.  Then, imagine a repo maintainer starts with 30 extra packages.
> Do you want him to remove a package from his repository when the same
> software is packaged in Extras by somebody else? 

If they fit the requirements to be in Extras, I'd prefer that they be put
there first, at least starting with new releases.   (Of course it isn't up to me
to do that...).  If they don't meet those requirements there isn't much chance
that they'll show up in extras later.

> Some independent
> packagers don't like to rely on infrastructure or procedures/policies,
> which they consider inferior to their own way of doing package releases,

Well, that was certainly true until recently when the 3rd party repositories
were the only ones so I hate to complain about their work now, but I still
don't see how it helps anyone to introduce a new package that conflicts
with an official version.

-- 
  Les Mikesell
   lesmikesell at gmail.com