On Thu, Dec 29, 2005 at 06:46:06PM +0100, Thorsten Leemhuis wrote:
> Am Donnerstag, den 29.12.2005, 12:30 -0500 schrieb Jeff Spaleta:
> > On 12/29/05, Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote:
> > > Then use a 3rd party repo that does not override Fedora Core or Extras
> > > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody
> > > stepped up to package it there. Any volunteers?
> >
> > I don't think this is a technically correct statement anymore to say
> > that Livna doesn't override Core and Extras. For example, audacity
> > exists in both Extras and Livna, with different compile options
> > because of mp3 support issues, i believe.
>
> /me checks and jeff seems to be right
>
> > And i think the maintainer of kdemultimedia-extras is working on a
> > similar livna/extras duplication arrangement.
>
> Yeah. It's a pity that both lack a plugin-system for stuff like
> mp3-support.
There are other examples as well. For giving a historical one: At some
time in the past RHL something was building samba w/o any ldap support
as this setup wasn't being supported by RH. Still the samba users
started harassing 3rd party repo maintainers to provide them with such
augmented functionality and some did so. This is just one example of a
stand-alone replacement ("stand-alone" as contrasted to replacements
made due to other packages requiring them). I'm not advocating that
this is good. Neither whether kdemultimedia-extras or audacity/mp3
overlap is good, or not. Just pointing out the neccessity for some
users.
I'd also prefer having plugin-architectures to everything so nothing
needs to be overlapping anymore. But other than the kernel there is
hardly something in a modular plugin architecture for packaging
purposes.
> But if the maintainer is the same in livna and extras I don't see a big
> problem -- yes, it's a problem, but has anybody a better solution? One
> idea: Create a sub-repo in livna with all the packages that
> replace/update/conflict with other Core or Extras packages.
That idea was there from the begining of the Fedora XXX repo
definitions, it was called Fedora Alternatives [1]. But no repo ever
accepted this idea, so it was dropped. It even disappeared from the
terminology web pages. This (dead-born) concept showed that it would
had been indeed helpful to discuss this with the community and the
third party repo maintainers before defining and publishing it, like
it is being done now for the yum plugin suggestion.
If you suggest "alternatives" to livna maintainership it will still
not have good chances of being accepted as it generates overhead w/o
any noticable benefits to both users and maintainers (other than
getting out of the discussion ;). Note that any package depending on a
package in an "alternatives" repo needs to be demoted to this repo,
too. So you may end up with quite a lot of packages in this at the
beginning-assumed-to-be-small side-repo.
[1] Fedora Alternatives suggested hosting at redhat.com, but the term
alternatives was mostly used w/o this hosting context.
> > This of course also makes the issue of protectbase on by default more
> > difficult, because if applied to Extras it would concievable hold-back
> > packages with mp3 support in livna that duplicate extras. And I
> > really can't imagine many users wanting that situation by default
>
> Probably.
--
Axel.Thimm at ATrpms.net
Attachment:
pgpJJd2fOOzVv.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
