half baked idea for further baking: "fedora-ugly" repo

Tadej Jane┼ż tadej.janez at tadej.hicsalta.si
Thu Feb 13 10:05:43 UTC 2014


On Tue, 2014-02-11 at 14:23 -0800, Toshio Kuratomi wrote: 
> 
> I think we need to support the use-cases of both Incubator (packages here
> are destined for Commons once the packages are polished up) and Ugly (these
> packages are usful for Fedora End Users to have access to but the upstream
> and downstream packaging is such that we'd never want to push them to people
> features as is).

+1

> I would like to avoid having two repositories for these two use cases if one
> repository would fit the bill.

+1. I also think the name of the repository should reflect that. I would
suggest something catchy, like Fedora Easy or Fedora Playground (Honza
Horak's suggestion), or something that would go with the Rings theme,
like Fedora Mantle (implying the main Fedora repo is Core).

> I think that many of these things get left out in the cold if we're
> specifying that the new repo doesn't support conflicts between the new repo
> and the Fedora Commons repo, the Core (once we figure out how to distribute
> that), or each other.

I think conflicts are an important thing to figure out before we
continue laying plans for this new repo.

I wouldn't throw all conflicts in the same bin. For example, I think
it's ok to bundle libraries (though it would be cool if we could somehow
detect it automatically and know which libraries are bundled), but I
would not be in favour of allowing package naming conflicts.

Regarding multiple parallelly installable versions of the same packages,
are SCLs going to give us that?
Also, SCLs could be useful when packages have file system conflicts. On
the other hand, would this be abusing SCLs?

> We would definitely want people to know that we weren't promising security,
> timely updates, etc... (indeed, we might want to tell people to expect
> insecure code, packages that would languish, etc...) as there would be
> a much higher duplication of code in this repo and likely more packages
> which included versions that were no longer accepted upstream.

+1.

Tadej



More information about the env-and-stacks mailing list